Azure is a platform of many services that call one another, plus your own apps and microservices that call those services and each other. The number of caller-to-target pairs is enormous, so the platform cannot solve access one pair at a time. It solves it with two shared systems, and keeping them apart is most of what this series is about.

Entra is the single identity authority. Every caller — a person, one of your apps, or an Azure service with a managed identity switched on — is a security principal in the tenant, and proves who it is by obtaining a short-lived signed token from Entra for a specific target. Managed identities are how Azure workloads get a principal without you ever handling a credential; app registrations are how your own apps and APIs get one, and how an API declares the permissions it understands. Azure RBAC is the single authorisation store for Azure resources, kept by Azure Resource Manager: rows of principal + role + scope, where a role is a set of actions and the scope is where it applies. Every request carries the token as a bearer header. The target verifies it offline with Entra’s public key, reads the caller’s object id from it, and only then decides. For an Azure resource that means consulting the role assignments Resource Manager holds — each service keeps a synced copy of the assignments that apply to it, which is why a new assignment can take a few minutes to take effect — and checking whether any of them grants this id the requested action at this scope. For your own API it means reading the roles or scopes Entra placed inside the token, because Resource Manager knows nothing about your API. Authentication is the token; authorisation is what the target does with it.

A Foundry agent adds nothing to this machinery. It adds callers — several of them, with different names and different defaults — and the governance question is simply which one makes which call. That sounds obvious until you try it. I ran one small experiment — a 124-page IMF World Economic Outlook embedded with text-embedding-3-small and loaded into Azure AI Search as 315 chunks — and a single agent question crossed two authentication boundaries, each authorised by a different identity, neither of them the one the portal puts in front of you. This post names them.

The vocabulary, in one pass

Six terms carry the whole series. If these are already second nature, skip to the next section.

First, the mechanism underneath all of them. Entra does exactly one thing: a caller proves who it is, Entra issues a signed token naming that caller and the intended target, the target validates the token and then decides — from its own role assignments — whether the operation is allowed. Authentication is the token; authorisation is what the target does with it. Managed identity is not an exception to this. When the Foundry project MI “calls” AI Search, the Azure fabric, which holds the identity’s certificate, performs a client-credentials request to Entra on its behalf, gets an ordinary access token, and Search sees nothing more than a bearer token with an oid it checks against RBAC. Keys, passwords and certificates differ only in how the caller proves itself; what crosses the wire to the target is always the same kind of token, which is why one set of checks covers the whole series.

• Tenant — your organisation’s Entra directory. Every identity below lives in it, and every token names it (the tid claim, and the tenant GUID inside the issuer URL).
• App registration — the definition of an application or API: its client id (appId), the scopes and app roles it exposes, and its Application ID URI, which becomes the aud in tokens sent to it. A registration cannot sign in or be granted anything; it is a blueprint, not an actor. One per client that requests tokens or resource that receives them.
• Service principal — the registration’s presence in a tenant: the actor. Role assignments, consent grants and the oid you see in tokens and sign-in logs all attach here, never to the registration. Keep the two ids apart: appId is for the protocol, the principal's object id is for authorisation and audit.
• Managed identity — a service principal Azure creates for a resource and whose credential Azure holds and rotates, so your code never sees a secret. System-assigned lives and dies with one resource; user-assigned is standalone and can be attached to many. A managed identity can call things but cannot be called: there is no registration behind it, so it exposes no scopes and is never an aud.
• Roles — two different systems that are easy to conflate. Azure RBAC authorises operations on Azure resources: principal + role + scope (Search Index Data Contributor on a search service). Entra app roles and scopes authorise calls to your APIs and arrive inside the token as roles (application) or scp (delegated, a user is present). Part I is all Azure RBAC; Parts IV–V are app roles and scopes.
• Token — a signed JWT from Entra. A receiving API checks signature, issuer, audience and lifetime, then reads oid (who), azp (through which app) and roles/scp (allowed to do what). A valid signature alone proves nothing about you: a Graph token is signed by the same keys as a token for your MCP server, which is why audience is the check that matters. Full validation walkthrough in Part IV.

With that: everything below is just “which service principal presented the token, and which role assignment let the call succeed”.

What Azure RBAC actually is

It is tempting to summarise Azure RBAC as “give each app a managed identity and add roles to it”. The second half is right; the first half is narrower than the real thing, and the gap is where misconfigurations hide.

Azure RBAC is a single store of role assignments. Each assignment is one row with three independent parts, and Azure Resource Manager (or the data-plane service itself) evaluates those rows on every request:

• Principal — any Entra security principal: a user, a group, a service principal you registered, or a managed identity. A managed identity is just the most convenient principal for a workload, because Azure holds its credential. Your own az login identity being Owner on the subscription is RBAC too — it is what let me create the index.
• Role definition — a named set of allowed operations, split into control-plane Actions (manage the resource: Microsoft.Search/searchServices/write) and data-plane DataActions (use the resource: Microsoft.Search/searchServices/indexes/documents/read). Owner, Contributor and Reader are control-plane only — which is exactly why being Owner gave my CLI identity no right to query the index, and ingestion fell back to an admin key.
• Scope — where the row applies, inheriting downward only: management group → subscription → resource group → resource. One assignment at subscription level reaches every search service in it; one at the search service reaches nothing else.

So the complete sentence is: RBAC assigns roles to principals at scopes; managed identities are the principals you use when the caller is a workload rather than a person. Two consequences follow for agents:

• The managed identity is not “the app having RBAC”. It is only the principal column of the row. You could give the same app a registration with a client secret and assign the identical roles to that service principal — same authorisation, worse credential hygiene. Managed identity changes how the caller authenticates, never what it is authorised to do.
• RBAC governs calls to Azure resources — Search, Storage, Key Vault, the Foundry project itself. It does not govern calls to your own API. When the agent calls the tickets MCP server in Part IV, the permission check happens inside that server, against app roles and scopes carried in the token (roles, scp); Azure Resource Manager is not consulted at all. "Where is this permission checked — in ARM or in the token?" is the question that separates the two systems, and every hop in this series has exactly one answer to it.

Rule of thumb. Use a managed identity for every Azure-to-Azure hop; it is the default, not an optimisation. Reach for something else only when a managed identity is impossible, and name which case you are in: the caller runs outside Azure (a CI runner, a laptop) → an app registration with a federated credential, still no secret; the target does not trust your Entra tenant (GitHub, a SaaS API) → that target’s own OAuth or key; a person must be represented in the call → a delegated token, never an app identity; the service simply does not accept Entra on the tier you are on (the Free-tier vectorizer here) → a key, in Key Vault, with an expiry and a ticket to remove it. Everything in this series that is not a managed identity is one of those four exceptions, and a production review should be able to point at which.

Three principals, not one

Microsoft Entra ID authenticates an identity and issues a token; the target service authorises the operation. For Azure resources that authorisation is an RBAC assignment: principal + role + scope. So the only question that matters at each hop is who is the principal.

A Foundry deployment has three of its own, and they are separate objects in your tenant:

1. Foundry resource managed identity — system-assigned, on the parent Foundry resource.

• Authenticates: resource-level operations, e.g. reading a customer-managed key in Key Vault.
• Roles go on: the resource it needs (Key Vault).

2. Foundry project managed identity — system-assigned, on the project.

• Authenticates: project connections set to use it — including the built-in Search, file-search and code-interpreter tools, which the Foundry runtime executes on the project’s behalf.
• Roles go on: the target service (here: AI Search).

3. Entra agent identity — a service principal Foundry provisions under an agent identity blueprint. In the current agent object model every new agent gets its own blueprint and a dedicated default identity at creation; only legacy agents share the project-level identity.

• Authenticates: tools reached through a project connection whose authentication type is agent identity. The tool kind alone does not decide this: an MCP or A2A connection can use it, while an OpenAPI connection set to managed identity runs as the project MI. Never the built-in tools.
• Roles go on: whatever those tools call.

Two consequences follow. Nesting is not inheritance: a role on the resource MI grants nothing to the project MI or the agent identity, and one project’s roles do not reach another project. And the agent identity, although it exists the moment you create an agent, is not the caller for a built-in Search tool — so putting Search roles on it would leave the real caller unauthorised.

(Microsoft’s Search-tool article mixes “account” and “project” MI wording; this post reports the connection as inspected — ProjectManagedIdentity — and the roles verified.)

The experiment: two calls, two authorisation decisions

Agent invokes the built-in Search tool
      │  caller: project MI
      │  grant:  Search Service Contributor + Search Index Data Contributor
      │          on the search service
      ▼
Azure AI Search index  (vectorizer on the vector profile)
      │  caller: Free tier      → apiKey of the Foundry resource (no role)
      │          Basic and above → the search service's system-assigned MI
      │  grant:  Cognitive Services OpenAI User on the Foundry resource,
      │          assigned to that search service MI
      ▼
Foundry embedding deployment (text-embedding-3-small)
      └─ query vector back to Search → matching chunks back to the agent

Boundary 1 — Foundry → Search. I added the index as a tool through a project connection and chose managed-identity authentication. That choice selects the credential Foundry presents; it grants nothing. On the search service’s IAM page the only principal with roles was me.

With Search Index Data Reader alone the tool failed. Reader permits the document query, so the failure most likely came from the connector’s service-level calls — listing indexes or reading the index definition — which need Search Service Contributor; I did not isolate the exact operation, so treat that as the probable cause rather than an observed one. The documented pair for the built-in integration is Search Service Contributor + Search Index Data Contributor, scoped to the search service, assigned to the project MI. That worked. Note that Data Contributor also permits writes and deletes: for a read-only agent this is broader than least privilege, and it is the kind of grant a production review flags.

What ended up assigned, for the record:

• Principal: the Foundry project managed identity (not the resource MI, not the agent identity).
• Roles: Search Service Contributor (control plane: list indexes, read index definitions — presumably what the connector needs to discover the index) and Search Index Data Contributor (data plane: query the documents; also write/delete, which is the over-grant noted above).
• Scope: the Azure AI Search service resource.
• Not assigned: anything on the agent identity, and nothing to the project MI beyond these two.

The rule: identify the caller, then assign the role.

On the wire: a managed-identity call is still a bearer token

It is worth being exact about what “the project MI calls Search” means, because the phrase hides the mechanism and the mechanism is where things break.

1. Token request, locally. The Foundry runtime asks the managed-identity endpoint (on your own compute this is the Instance Metadata Service at 169.254.169.254, reachable only from inside the resource) for a token with resource=https://search.azure.com.
2. Client-credentials grant, by Azure. The Managed Identity resource provider holds the identity’s certificate — the credential you never see and never rotate — and uses it to authenticate to Entra on the identity’s behalf. Entra returns an ordinary JWT access token.
3. The HTTP request. Search receives a plain REST call. The only thing managed identity changed is one header: Authorization: Bearer <JWT> where a key-based connection would have sent api-key.

POST https://my-search.search.windows.net/indexes/weo-index/docs/search?api-version=2024-07-01
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ij...
Content-Type: application/json
{ "search": "IMF global growth projection 2026",
  "vectorQueries": [{ "kind": "text", "text": "IMF global growth projection 2026",
                      "fields": "contentVector", "k": 10 }],
  "top": 10 }
----- decoded payload of that bearer token -----
{ "aud":   "https://search.azure.com",
  "iss":   "https://sts.windows.net/<tenant id>/",
  "oid":   "<object id of the project MI's service principal>",
  "appid": "<client id of the project MI>",
  "idtyp": "app",
  "exp":   1762188700 }          <- no roles, no scp: identity only

Search then does two things, in order, and the status code tells you which one failed:

• Validate the token — 401 if this fails. Read kid from the header, verify the RS256 signature against Entra's published public keys (cached JWKS), check the issuer is a trusted tenant, check aud is its own audience https://search.azure.com — a perfectly valid Storage token presented here fails right there — and check nbf/exp. No call to Entra is needed; the signature is enough. Search now believes "the caller is oid X".
• Authorise the action — 403 if this fails. Map the request to a data action (Microsoft.Search/searchServices/indexes/documents/read), then evaluate Azure RBAC for that oid: walk the scope chain from the service up through resource group, subscription and management group, collect role assignments and deny assignments, and check whether any effective DataActions − NotDataActions includes the action. Match → run the query → 200.

Notice what a role assignment therefore is and is not. It is one row in Azure Resource Manager — principal, role, scope — read by the target service at request time. It is not something that enables token issuance: Entra will mint the project MI a Search token whether it holds a role on any search service or not, and the token looks identical either way. Managed identity automates proving who is calling (the principal, the certificate, the token request, rotation, cleanup). It never automates deciding what that principal may do; that stays an explicit assignment, and the default is nothing — a project’s MI holds no rights on its own parent resource, let alone on your search service, until someone writes the row.

Two things this picture is not saying, because both are common misreadings. First, requests do not go through Entra, and not every request gets a new token. Entra is out of band: the caller talks to it once to obtain a token, caches it for its lifetime (about an hour), and only returns when it is near expiry. A thousand searches in an hour are one trip to Entra and a thousand trips to Search, and an unexpired token keeps working if Entra is unreachable. Search does not call Entra either — it checks the signature with Entra’s public key, which it already holds. Entra issues; it does not sit in the path.

Conversation 1 — obtain a credential (rare; cached ~1 h)
  caller ──► Entra   "token for https://search.azure.com; proof: MI certificate"
  Entra  ──► caller  JWT
Conversation 2 — do the work (every request; direct)
  caller ──► Search  POST /indexes/weo-index/docs/search
                     Authorization: Bearer <that JWT>
  Search ──► caller  200 results  |  401 (not my token)  |  403 (no permission)

Second, nothing is “wrapped” in the token. The request is an ordinary HTTPS call and the token is one header on it, next to Content-Type. TLS protects it in transit — which is the only reason a bearer credential is acceptable: whoever holds it can use it, so it must never travel in the clear, never be logged, and must expire quickly. The working analogy is a passport: issued by one authority, checked at many borders, none of which telephone the issuing office.

Boundary 2 — Search → the embedding model. The stored vectors were already there; to vectorise the query at search time, the index needs an Azure OpenAI vectorizer on the vector field’s profile. The vectorizer is itself a caller and needs a credential:

• Free tier — credential: apiKey, the key of the Foundry / Azure OpenAI resource hosting the embedding deployment (a secret stored in the index definition; remove in production). Role needed: none.
• Basic and above — credential: the search service’s own managed identity; omit apiKey, use authIdentity only to pin a user-assigned MI. Role needed: Cognitive Services OpenAI User on the Foundry resource.

The vectorSearch block I used (portal: Search service → Indexes → index → Edit JSON; replace only this section):

{
  "vectorSearch": {
    "algorithms": [{ "name": "weo-exhaustive", "kind": "exhaustiveKnn",
                     "exhaustiveKnnParameters": { "metric": "cosine" } }],
    "profiles":   [{ "name": "weo-vector-profile", "algorithm": "weo-exhaustive",
                     "vectorizer": "weo-query-vectorizer" }],
    "vectorizers": [{
      "name": "weo-query-vectorizer", "kind": "azureOpenAI",
      "azureOpenAIParameters": {
        "resourceUri": "https://YOUR-RESOURCE.openai.azure.com",
        "deploymentId": "text-embedding-3-small",
        "modelName": "text-embedding-3-small",
        "apiKey": "<FOUNDRY_RESOURCE_KEY>"
      }
    }],
    "compressions": []
  }
}

On Basic and above the direction of the grant flips. The caller is now the search service’s system-assigned managed identity (turn it on under the search service’s Identity blade first), and the role — Cognitive Services OpenAI User — is assigned on the Foundry resource with that search MI as the assignee. Boundary 1 put a Search role on a Foundry identity; Boundary 2 puts a Foundry role on the Search identity. Same rule both times: find the caller, then grant on the target.

Query and document embeddings must share model and dimensions; a caller that already supplies a numeric vector bypasses the vectorizer entirely.

Make retrieval explicit, then prove it

Adding a vectorizer does not change how the agent searches. I set the tool to

"query_type": "vector_simple_hybrid",
"top_k": 10

— keyword plus vector, up to ten chunks per query, no semantic reranking.

Evidence that retrieval happened: the agent’s full API response contained a completed azure_ai_search_call with its returned content. A fluent answer or a citation is not evidence. Traces are the second source — look for the azure_ai_search_call span and its connection — though in this run the traces UI lagged Application Insights, which already held the spans.

Observations worth keeping:

• Citation URLs point at the Search endpoint, not PDF pages.
• My az login was a fourth principal: being Owner conferred no data-plane rights, and ingestion fell back to a Search admin key after a 403. Another credential to retire.
• Setup: 7.88 MiB of the Free tier’s 50 MiB, one of three index slots, 1,536-dimensional vectors, text only (no chart interpretation). Search stayed within quota; embedding calls were billed separately.

What a reviewer would say

We can name caller, credential, target and permission at each boundary — the project MI for the Search connection, the vectorizer’s key for the model call — and the agent identity, although present, called nothing. A production review would flag two items in this setup: Data Contributor on a read-only path, and a key inside the vectorizer. Both are fixable; both are invisible if you only check that the agent answers.

Where the series goes next

Each part adds exactly one mechanism, so tool approval, OAuth consent, downstream authorisation and inbound authorisation stay distinguishable.

• Part II — public MCP and the approval loop. Microsoft Learn MCP, no auth, require_approval on; inspect the approval request; then allowed_tools = ["microsoft_docs_search"]. Lesson: approving a tool call is an execution decision, not an identity grant.
• Part III — third-party OAuth and consent. The managed GitHub MCP connector; the consent-required flow; whose account grants access and which scopes.
• Part IV — our own MCP API and the agent identity. A small tickets API with get_ticket, an Entra app registration with app role Tickets.Read; validate signature, issuer, audience, lifetime, then enforce the role. Denied before the grant (403 — valid token, missing permission; 401 is a different failure), successful after assignment to the actual agent principal. Then a second, separately tested hop: the MCP server reads the ticket from Azure Storage using its own managed identity (Storage Blob Data Reader on the container). Two grants, two principals — the agent identity is authorised to invoke get_ticket; the server MI is authorised to read the data. Neither grant implies the other.
• Part V — agent-only versus user-delegated. A user-entra-token connection to the same API; compare the validated claims side by side — oid, aud, roles versus scp. Record selected claims, never raw bearer tokens.
• Part VI — an application calls the agent. The inbound side, untested so far: a small client app hosted in Azure invokes the Foundry agent with its own managed identity, and we separate the application’s permission to call the agent (an Azure AI User-class role on the Foundry project) from the agent’s permission to call its tools. Run it twice, with a system-assigned and then a user-assigned MI, to show what changes in the token and in the role assignments when the identity outlives the app.

Taken together the series then covers the four places an identity appears: the application calling in, the Foundry runtime identities, the agent identity calling out, and the tool server’s onward identity. The resource MI’s Key Vault role stays explanatory unless an encryption lab becomes worth its own part.

The evidence pattern throughout: a denied call, the precise grant that changes the outcome, the successful call, and the token that proves who made it.

References

• Connect an Azure AI Search index to Foundry agents — Microsoft Foundry docs; names Search Index Data Contributor + Search Service Contributor on the search service for keyless connections (and mixes account/project MI wording).
• Agent identity blueprints: dedicated vs. shared identities and supported tools — Microsoft Foundry docs.
• Agent identity blueprint — Microsoft Entra Agent ID docs.
• Connect to Azure AI Search using roles — what Search Service Contributor and Search Index Data Contributor each permit.
• Azure OpenAI vectorizer — Azure AI Search docs; apiKey vs authIdentity, and "requires only the Cognitive Services OpenAI User role on the target resource".
• Access token claims reference — Microsoft identity platform (aud, oid, scp, roles).
• How managed identities for Azure resources work with Azure virtual machines — Microsoft Entra docs; the IMDS endpoint, the certificate issued by the Managed Identity resource provider, and “Microsoft Entra ID returns a JSON Web Token (JWT) access token”.
• How Azure RBAC determines if a user has access to a resource — Azure RBAC overview; the evaluation order including deny assignments and DataActions − NotDataActions.

Agent Governance on Microsoft Foundry, Part I: Which identity makes the call? was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

Java 8 has been part of that work too, with help from the fine folks at the Eclipse Foundation’s Eclipse Adoptium project. Microsoft has supported Java 8 on Azure using their Eclipse Temurin builds of OpenJDK 8, rather than producing a Microsoft Build of OpenJDK 8. That collaboration goes back to the launch: our first Java 11 builds also used Adoptium’s build scripts and quality assurance suite.

Supporting those releases has meant years of updates. Now it’s time to plan the next move.

The Microsoft Build of OpenJDK support roadmap lists September 2027 as the earliest end-of-support date for Java 11 and 17. That’s a distribution-wide milestone: if you use those Microsoft builds on a VM, in a container, on Kubernetes, on Azure platform services, or evem outside Azure, it belongs in your upgrade planning. These dates are initial targets, and Microsoft may extend them. However, consider taking action now.

Azure services also have their own deadlines. Azure App Service and Azure Functions support for Java 8, 11, and 17 ends on September 1, 2027. Existing applications will continue to run, but the affected Java versions will no longer receive security updates, improvements, or related customer support.

If that’s your application, the practical question is how to get to Java 21 or 25 while keeping it working. GitHub Copilot modernization gives you a tool: the Modernize CLI, which can assess your code, help plan the upgrade, and actually perform and apply changes for you to review.

Continue reading on the Java at Microsoft blog…

Plan Your Java Upgrade Ahead of Microsoft’s 2027 Support Milestones was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

I briefly introduced this pattern in my book, The Azure Cloud Native Architecture Mapbook https://www.amazon.com/Azure-Cloud-Native-Architecture-Mapbook/dp/1805805053, but I would have explored it in much greater depth had I realized how many misconceptions surround it.

Introducing the BFF in a nutshell

Initially, the sole purpose of a BFF was to be a tailor-made backend for a specific type of frontend, such as a mobile app or a single page application. The BFF is the bridge between the frontend and the actual backends.

The frontend only talks to the BFF, which in turn routes traffic to the actual backends. The BFF can be more than a mere router when using GraphQL to strongly decouple frontend and backend development teams. On the technical level, this also helps prevent underfetching and overfecthing as well as gaining flexibility for frontend queries. While GraphQL is optional, it often plays well with the BFF pattern.

How the BFF turned into a security thing

A few years after having become more popular, the BFF made its way into the OAuth world and is even proposed in this OAuth RFC candidate https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps

When used as a security pattern, the BFF becomes the actual OAuth client instead of the frontend application. As a result, no OAuth tokens, whether ID tokens, access tokens, or refresh tokens, are ever exposed to the client (e.g. browser).

This is a significant security improvement because browser-based applications are inherently more vulnerable to client-side attacks, such as Cross-Site Scripting (XSS), which can allow malicious actors to steal tokens and impersonate users.

With the BFF pattern, the frontend never handles OAuth tokens directly. Instead, the browser exchanges only a secure, HTTP-only, Secure and SameSite-protected session cookie with the backend. Because this cookie is inaccessible to client-side JavaScript, the attack surface is significantly reduced.

Before diving into the security controls you can enforce for the BFF pattern, let’s look at the actual authentication and authorization flows, taking Entra ID as the identity provider and authorization server.

Here is a direct pointer to the diagram https://raw.githubusercontent.com/stephaneey/azure-and-k8s-architecture/refs/heads/main/networking/bff/bff-flows.png

In the example above, I’m using Entra ID but the same concepts apply to most providers. I’m also using API-led connectivity to illustrate that a given token should not traverse API layers, but new tokens should be requested instead for each layer and each API of that layer. Here is a step by step recap:

1 Login: the client connects to the BFF, which returns a 302 redirect.

2 User authentication: the BFF redirects the browser to Entra ID; the user signs in using the BFF client app (authorization code flow + PKCE).

3 Callback: Entra redirects to the BFF redirect URI with the authorization code. The BFF redeems it with its confidential credential for ID + refresh + access tokens and stores them in the token cache store (e.g Redis).

4 Session cookie: the BFF returns a HttpOnly; Secure; SameSite cookie. It is only a session handle: no token ever reaches the browser.

5 API calls: the SPA calls /bff/<app-specific-bff> with the cookie only; the BFF looks up the user’s tokens in the cache.

6 / 6' Token request: the BFF uses the refresh token to get an access token for Experience/Process API 1 / 2 — one token per audience, cached until it expires.

7 / 7' Routed call: the BFF forwards the call to Experience/Process API 1 / 2 with the matching bearer token. Resource servers (target APIs) validate issuer, audience and scopes.

8 On-behalf-of: Experience/Process API 1 request a new access token targeting a sytem API, using the incoming user token. OBO is only used when the System API needs the user context.

8' Client credentials: when user context is not needed at system API level, an app-only token is obtained using the Client Credentials Grant Flow (CCF).

9 / 9' System API call: Experience/Process APIs calls System APIs with a bearer token, obtained with OBO or CCF, issued for that System API’s audience.

So the key takeaways of the above diagram are:

• The BFF is a security component. It acts as the OAuth client and manages tokens for all sessions. You would typically choose a distributed token cache store such as Redis to avoid sticky sessions and make sure cache can scale. Only use in-memory cache store for testing or demo purposes.
• Make sure to request resource-specific tokens and that a given token type doesn’t traverse the different API layers no even the different APIs belonging to the same layer.
• Because the BFF handles the authentication, it must accept anonymous requests, or at least, clients will perform unauthenticated calls for the very first access. This alone, is often a friction point with security teams and we’ll see how to overcome and mitigate this problem in thef following sections.

Hosting the BFF in Azure

The BFF can be hosted in many different ways:

• As an Azure App Service or an Azure Function
• On a container orchestration platform such as Azure Kubernetes Service, Azure Container Apps or Azure Red Hat OpenShift

The number of security controls you can enforce depends on the Azure service you choose. Container orchestrators let you use Service Meshes, App Service’s Easy Auth feature may play a role as well. There are multiple infrastructure-level features that help you ensure secure access to the BFF.

As you’ve probably gathered by now, the BFF must be accessible from the frontend. Consequently, for an internet-facing application, the BFF itself must also be internet-facing.

To be precise: the BFF itself doesn’t need to behind a public IP but it must be placed behind a Web Application Firewall (WAF) and/or an API gateway since the client (mobile or browser) must be able to access it. This is only true for internet facing applications of course. This consideration doesn’t apply for internal corporate apps whether mobile or SPAs, where clients are connected to the internal network perimeter. I’m only considering internet facing apps here, which is where you might have endless discussions with security teams. The below diagram shows a high-level flow for an internet facing BFF.

Here is a direct pointer to the diagram https://raw.githubusercontent.com/stephaneey/azure-and-k8s-architecture/refs/heads/main/networking/bff/bff-with-or-without-gtw.png

Because of the internet facing nature of the BFF, using a Web Application Firewall (WAF) is a non-negotiable fact. Then comes the interesting piece, should you use an API gateway or not in front of your BFF?

As a reminder, the BFF isn’t a regular API and must support anonymous calls from the client, or at least, the client should be able to reach out anonymously, which isn’t exactly the same thing.

Additionally, even once the user signed in and the first tokens were acquired by the BFF, they will never be sent back to the browser. This means that the gateway will never be able to validate any token since there is none. The only thing the gateway will see is a session cookie, which cannot really by validated by typical API gateway policies.

However, many security teams cannot leave with the fact that a component that is not in the public edge would receive anonymous calls. This gives them cold sweats and since we love them, we want to preserve their health!

This is where the gateway can play an interesting role. Find below an overall security-driven architecture for a bullet proof BFF.

Here is a direct pointer to the diagram https://raw.githubusercontent.com/stephaneey/azure-and-k8s-architecture/refs/heads/main/networking/bff/bullet-proof-bff.png

In the above diagram, I implement the following security controls:

1. Azure Front Door Premium is the only internet-facing endpoint: WAF L7 inspection, DDoS protection, IP / geo restrictions and custom WAF rules. Front Door is the public edge, noting else has an inbound public IP. Additionally, beyond security, Front Door helps build resilient multi-region architectures.
2. Front Door reaches the App Gateway over Private Link only. Private listener only. Private Link connection approved for this Front Door profile only.
3. IDPS with Azure Firewall Premium. Additional traffic inspection is questionable for this flow but limited IDPS is still possible without inspection.
4. APIM inbound policy on every /bff/<app-bff> endpoint:
   (a) authenticates with its system-assigned managed identity (token for a backend app registered in Entra with the Gateway.Invoke role.
   (b) sends the token in a dedicated header for the BFF (X-Gateway-Authorization), validated by Istio on the BFF istio-proxy sidecar (I’ll come back to this) but key fact: traffic is authenticated before it reaches the BFF, exactly what security teams want.
5. NSG inbound rules restrict access to APIM and other internal callers if any.
6. AKS internal load balancer which doesn’t enforce any security control but is on the data path.
7. /7'. NSG inbound rules restricted to the Azure load balancer and K8s system ports, limiting node-level lateral movement. The ingress controller as well as the BFF pod live in an ingress node pool and dedicated ingress subnet to not mix such pods with the real backend ones.
8. Istio Gateway API; mTLS between ingress controller and istio-proxy sidecar.
9. istio-proxy validates the gateway token and forwards traffic to the BFF container, which ensure no unauthenticated calls can ever reach the BFF container, regardless of the BFF code.
10. BFF handles the authentication bits, token cache, etc.
11. /11' Calico or Cilium network policies control traffic across namespaces, with global deny policies by default.
12. Istio validates fine-grained authorizations between BFF and backend pods; also performs OAuth token validation.
13. NSG inbound rules restrict access to the user node pool subnet.
14. Workload identity used to authenticate against Azure services
15. PaaS services all behind private endpoints, public access denied
16. Image pull restricted to ACR and MCR
17. Key Vault CSI driver
18. Data encrypted at rest
19. / 19' / 19'’ Cluster internet-bound traffic routed to the egress hub Azure Firewall. You might enable TLS inspection depending on the use case.
20. Log retention 90 days; monitoring alerts with Azure Monitor and Container Insights.

So, I hope you noticed by yourself but I will still help you in case you didn’t! With the above setup, the traffic never reaches the BFF anonymously, although it is required by the client. So, what we do is this:

Browser ─▶ WAF ─▶ APIM (Anonymous) ─▶ APIM Authentication (gateway token) ─▶ Istio Token Validation (sidecar) ─▶ BFF container ─▶ Response

So, regardless of the BFF’s code quality, the surrounding components will ensure nothing can reach the BFF pod unauthenticated.

Worth to mention that cluster-wide settings for both Istio and Calico/Cilium are enforced to make sure everything is denied by default. You would also apply Azure Policy for Kubernetes to make sure deployments are fully hardened.

If you deal with a multi-tenant AKS cluster, you would keep the same approach but isolate workloads into their own dedicated landing zone.

The biggest change compared to the previous setup is the introduction of a dedicated Istio ingress and egress gateway per landing zone. In the previous setup (dedicated cluster), a single ingress controller is enough. No egress controller is required since you know the cluster belongs to a single application, which makes it easy to identity the caller for downstream services. In a multi-tenant cluster, having a dedicated egress controller with a static IP per landing zone is required to restrict access to downstream services, from the downstream services perspective.

Key takeaways

• The single entry point for internet traffic is Front Door, nothing else.
• You can leverage APIM to expose an anonymous front leg to the client (the browser) but have an authenticated back leg to the BFF.
• You can leverage infrastructure-level technologies such as Istio to validate tokens issued by APIM and ensure that only authorized traffic originating from APIM can reach the BFF.
• Note that this architecture is primarily security-driven and comes with its own trade-offs. The multiple network hops required to reach the BFF pod introduce additional latency and processing overhead, potentially impacting performance and scalability. Make sure to evaluate these trade-offs against your key architectural drivers and non-functional requirements.

Bullet proof security-driven BFF architecture in Azure was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

Justin Fine, Idris Motiwala, Tushar Goyal

Microsoft Fabric Graph removes the previous hop limit for variable-length traversals, allowing graph structure to determine path depth.

Graph analysis is often about discovering how entities connect when the number of relationships between them isn’t known in advance. A message might be part of a reply chain that is three levels deep — or thirty. A component might depend on another component through an unpredictable number of intermediate services. An organizational hierarchy might vary significantly across teams.

Microsoft Fabric Graph can now query unbounded variable-length paths, enabling traversals of relationships without specifying a fixed maximum number of hops while also being able to specify very large numbers for the upper bound.

Previously, variable-length traversals supported a low number of maximum hops. That limit worked well for many scenarios, but it required developers to choose an upper boundary even when the structure of the data should determine the traversal depth. With this update, a path can continue beyond this limit until the query finds a matching destination or no valid continuation remains.

What is a graph traversal?

A graph represents entities as nodes and the relationships between them as edges. For example, a social graph might include people, messages, posts, and forums as nodes. Relationships such as replied to, belongs to, or moderates connect those nodes.

A traversal follows relationships through the graph. A single-hop traversal answers a direct question, such as which post a message replies to. A multi-hop traversal follows a chain, such as identifying the original post in a reply thread or the upstream system supplying a dataset.

These chains don’t always have predictable depth. Requiring every query to specify a maximum can produce incomplete results when the selected limit is lower than the depth of the underlying data.

From bounded traversals to data-driven traversals

Before this update, a variable-length path could traverse up to predefined number of relationships. Developers could query a range of path lengths, but every query remained subject to that maximum.

Unbounded variable-length paths remove the ceiling. Instead of deciding in advance how deep the query should search, users can express the relationship pattern they want to follow and allow the graph structure to determine the required depth.

This change applies to scenarios such as:

• Conversation analysis: Follow reply chains back to their originating post.
• Data lineage: Trace upstream or downstream dependencies across complex pipelines.
• Dependency management: Identify transitive software, service, or infrastructure dependencies.
• Organizational analysis: Navigate reporting or ownership hierarchies of varying depth.
• Knowledge graphs: Follow semantic relationships until a relevant entity is found.
• Fraud and security investigations: Explore chains of related accounts, devices, events, or transactions.
• Supply-chain analysis: Trace materials, suppliers, and distribution relationships across multiple tiers.

Queries can express the intent of retrieving unbounded paths, but not the use of unlimited system responses. They continue to operate within applicable service protections, including execution time, capacity, memory, and result-size constraints.

Following an unbounded reply chain

Consider a social network graph containing messages, posts, forums, and people. A message can reply to another message, which can reply to another message, eventually reaching the post that began the conversation.

The following query starts with a specific message and follows the REPLY_OF relationship for as many steps as needed to reach a post. It then identifies the forum containing that post and returns the forum’s moderator.

In this query, starting with this message, keep following the reply chain until you reach the original post. Then return the forum that contains the post and the person who moderates it.

:params { messageId: 206158431836 } 
 
MATCH 
 (message:Message {id: $messageId}) 
 -[:REPLY_OF]->* 
 (post:Post) 
 <-[:CONTAINER_OF]- 
 (forum:Forum) 
 -[:HAS_MODERATOR]-> 
 (moderator:Person) 
RETURN 
 forum.id AS forumId, 
 forum.title AS forumTitle, 
 moderator.id AS moderatorId, 
 moderator.firstName AS moderatorFirstName, 
 moderator.lastName AS moderatorLastName

The query contains four logical steps:

1. Find the starting message. (message:Message {id: $messageId}) identifies the message supplied through the query parameter.
2. Follow the complete reply chain. -[:REPLY_OF]->* repeatedly follows outgoing REPLY_OF relationships. The traversal isn’t restricted to a limited number of hops, so deeply nested conversations can still reach their originating post.
3. Find the containing forum. (post:Post)<-[:CONTAINER_OF]-(forum:Forum) identifies the forum associated with the post.
4. Return the forum moderator. (forum:Forum)-[:HAS_MODERATOR]->(moderator:Person) connects the forum to its moderator, whose identifying information is returned.

Bounded paths still matter

Unbounded paths expand what graph queries can express, but they don’t replace bounded traversal.

MATCH (message:Message {id: $messageId})-[:REPLY_OF]->{5,23}(reply:Message) RETURN reply

A bounded path remains the better choice when the business question has a natural maximum. For example, an application looking for professional connections within three degrees should state that limit. A query evaluating only immediate and secondary dependencies should also use a bounded range.

Use a bounded path when:

• The maximum useful depth is known.
• Connections beyond a certain depth aren’t relevant.
• Predictable query cost or latency is important.
• The graph is dense and each additional hop could produce many more candidate paths.

Use an unbounded path when:

• The required depth is unknown.
• The query must reach the end of a hierarchy or chain.
• An arbitrary upper limit could omit valid results.
• The data provides a natural termination point, such as a root node or destination label.

The best path expression is the narrowest one that completely answers the business question.

Design efficient unbounded traversals

Removing a fixed hop ceiling makes query design even more important. The number of possible paths can grow quickly in a densely connected graph, particularly when nodes have many outgoing relationships, here are some recommendations:

• Start with a selective node

Anchor the traversal to a specific entity whenever possible. In the example, the message ID provides a precise starting point and avoids scanning reply chains for every message.

• Specify relationship and node labels

A traversal that names REPLY_OF, Post, and Forum is more targeted than one that follows any relationship to any node. Expressing the intended graph structure constrains the search and makes the query easier to understand.

• Apply filters early

Place selective conditions as close as possible to the relevant node or relationship pattern. Early filtering reduces the number of candidate paths that later stages must process.

• Return only the required data

Project the properties needed by the application instead of returning every node, edge, or property encountered during traversal. Smaller results are easier to process and transfer.

• Account for cycles

Some graphs contain relationships that can lead back to previously visited entities. Model traversal patterns carefully and use supported path modes (ASYCLIC, TRAIL, WALK, etc) or predicates when the scenario requires protection against repeated nodes or edges.

• Test with representative data

A query that performs well on a small development graph can behave differently when applied to a dense production graph. Test using realistic path depths, relationship density, and result sizes. Monitor execution behavior before incorporating an unbounded traversal into a production workload.

Next steps

Explore unbounded variable-length paths with a scenario in which relationship depth varies across your data. Evaluate the query with representative graph density and path lengths before using it in a production workload.

• Graph in Microsoft Fabric overview
• GQL language guide for graph in Microsoft Fabric
• Optimize GQL query performance for graph in Microsoft Fabric

Tags: #Graph, Graph Query Language (#GQL), data relationships, graph traversal, #graphsareeverywhere

Explore deeper connections with unbounded variable-length paths in Microsoft Fabric Graph was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

January–August 2026 updates expand how users find, inspect, compose, and analyze connections.

Graph data helps organizations understand connections: how data moves between systems, how services depend on one another, how conversations develop, and how people or organizations relate. Graph Query Language (GQL) provides a standardized way to ask those questions in Microsoft Fabric Graph.

From January through August 2026, the GQL feature set expanded across path finding, traversal control, query composition, aggregation, and data handling. The result is broader analytical coverage for business users and more precise query tools for developers. This post explains each improvement and includes the associated syntax.

Find and control paths

Shortest paths with ANY SHORTEST

When several routes connect two entities, many applications need one shortest route rather than every possible route. ANY SHORTEST makes that intent explicit. This is useful for dependency analysis, recommendations, network routing, and investigations where fewer intermediate steps are preferred.

MATCH ANY SHORTEST ({id: 1})->{,2}(d) 
RETURN d.id AS dst

Quantified edge patterns

Quantified edge patterns repeat a complete relationship pattern, including conditions on intermediate entities. In the following example, the repeated pattern requires the source person at each step to use Chrome. This gives developers more control than repeating an edge alone.

MATCH p=(a:Person {id: 987})((x)-[k:knows]->() WHERE x.browserUsed = 'Chrome'){2}(b:Person) 
FOR n IN NODES(p) WITH OFFSET off 
RETURN n.browserUsed 
ORDER BY a.id, b.id, off 
LIMIT 12

Complete path modes

Path modes define whether a traversal can revisit nodes or edges.

• WALK permits repetition.
• TRAIL prevents repeated edges.
• SIMPLE prevents repeated interior nodes.
• ACYCLIC prevents any repeated node.
• DIFFERENT EDGES prevents one edge from satisfying more than one edge variable in the match.

These choices help query results reflect the meaning of a route, hierarchy, or dependency chain.

MATCH WALK (:Person {firstName: "Juliana"})-[:studyAt]->(:University)<-[:studyAt]-(p:Person) 
RETURN p.firstName AS name

MATCH TRAIL (:Person {firstName: "Juliana"})-[:studyAt]->(:University)<-[:studyAt]-(p:Person) 
RETURN p.firstName AS name

MATCH SIMPLE (x)->{2}(y) 
RETURN COUNT(*) AS path_count

MATCH ACYCLIC (x:`node` {id: 1})->(y)->(z) 
RETURN x.id, y.id, z.id 
ORDER BY x.id, y.id, z.id

MATCH DIFFERENT EDGES (p:Person {name: 'Keanu Reeves'})-[e:ACTED_IN]->(m:Movie) 
RETURN m.title AS movie

Unbounded variable-length path patterns

Variable-length paths previously had a limited maximum hop. Unbounded quantifiers allow the graph structure to determine depth when a chain has no meaningful fixed limit. The example follows one or more relationships while ACYCLIC prevents a node from being visited twice. Unbounded describes the path expression, not unlimited compute; selective starting points and representative performance testing remain important.

MATCH ACYCLIC ()-[]->{1,}() 
RETURN COUNT(*) AS total

Inspect paths and graph elements

NODES, EDGES, and INNER_NODES

These functions expose the contents of a matched path. NODES returns all nodes, EDGES returns its relationships, and INNER_NODES returns the intermediate nodes without the endpoints. They help applications explain lineage, dependencies, and investigative findings instead of returning only the destination.

MATCH p=({id: 1})-[]->{0,4}(z) 
RETURN NODES(p) AS res_nodes, 
 INNER_NODES(p) AS res_inner_nodes 
ORDER BY z.id

ELEMENT_ID

ELEMENT_ID returns the identity of a graph element. It is useful when an application must compare, track, or reference a specific node or edge independently of its business properties.

MATCH (x) 
RETURN ELEMENT_ID(x) AS vid, x AS actual_id 
ORDER BY x.id 
LIMIT 5

SOURCE and DESTINATION

SOURCE and DESTINATION identify the endpoints of an edge. This makes directional checks and edge-centric analysis easier, especially when a query starts from a relationship rather than a node.

MATCH (x)-[e]->() 
RETURN x.id, SOURCE(e).id AS s 
ORDER BY e.src, e.dst 
LIMIT 10

MATCH ()-[e]->(x) 
RETURN false IN COLLECT_LIST(x = DESTINATION(e)) AS no

Compose larger queries

NEXT

NEXT passes the output of one query stage into the next. Analysts can describe a multistage question in the order they reason about it: calculate a measure, filter the result, follow another relationship, and then summarize again.

MATCH (m:Message)-[:hasCreator]-(p:Person) 
RETURN p, AVG(m.length) AS avg_msg_length GROUP BY p 
NEXT 
FILTER avg_msg_length > 100u 
MATCH (p)-[:knows]->(:Person) 
RETURN avg_msg_length, COUNT(*) AS connections 
GROUP BY p, avg_msg_length

EXISTS subqueries

EXISTS answers a yes-or-no question about another graph pattern. It can filter rows or participate inside an aggregate without requiring the outer query to return the matching details.

MATCH (x) 
WHERE EXISTS { 
 MATCH (y) 
 WHERE y.id = 5 
 RETURN y 
} 
RETURN x.id AS xid 
ORDER BY xid
MATCH (x) 
RETURN COUNT(*) FILTER ( 
 WHERE EXISTS { MATCH (x)-[]->(y) RETURN y } 
) AS count_with_out

CALL subqueries

CALL runs a contained query for the current outer result. The example calculates each node’s outgoing degree in a focused block and then returns it with the node identifier.

MATCH (x) 
CALL { 
 MATCH (x)-[e]->(y) 
 RETURN COUNT(e) AS out_degree 
} 
RETURN x.id AS xid, out_degree 
ORDER BY xid

OPTIONAL CALL

OPTIONAL CALL preserves the outer row when the contained query has no match. This supports enrichment scenarios where related information is useful but not required.

MATCH (x {id: 1}) 
OPTIONAL CALL { 
 MATCH (y)-[]->(x) 
 RETURN y.id AS yid 
} 
RETURN x.id AS xid, yid 
ORDER BY yid

UNION DISTINCT

UNION DISTINCT combines compatible result sets and removes duplicate rows. It complements UNION ALL, which preserves duplicates, so the query can choose the correct set behavior.

MATCH () LIMIT 3 
RETURN 42 AS x 
UNION 
MATCH () LIMIT 3 
RETURN 100u AS x

Summarize connected data

Filtered and paged aggregates

Filtered aggregates calculate a summary over a selected subset. Paging controls such as LIMIT can be applied within the aggregate, giving developers precise control over which values contribute to the result.

MATCH (m:Movie) 
RETURN COUNT(*) FILTER (WHERE m.released < 1980 LIMIT 10) AS filtered_count

Nested aggregations

Nested aggregation supports layered questions, such as finding the minimum of averages calculated across groups or paths. This reduces the need to move intermediate results into application code.

MATCH (a:`node`)-[e:`edge`]->{1,2}(b:`node`) 
RETURN a.id AS id, MIN(AVG(e.weight)) AS min_average 
GROUP BY id

COLLECT_ONE, COLLECT_LIST, and COLLECT_ELEMENTS

Collection functions retain values or graph elements for evaluation as a group. COLLECT_ONE selects one value, COLLECT_LIST builds a list, and COLLECT_ELEMENTS gathers graph elements. They are useful for path-level checks, ordered output, and analysis across repeated relationships.

MATCH (p:`node` {id: 1})-[e]->{2}(p1:`node` {id: 1}) 
RETURN (COLLECT_ONE(e.weight) IN [e[0].weight, e[1].weight]) AS contained

MATCH ()-[e]->{1,2}() 
RETURN COLLECT_LIST(ALL e.weight) AS w 
ORDER BY w 
LIMIT 20

MATCH ()-[a:ACTED_IN]->{0,4}() 
WHERE SIZE(COLLECT_ELEMENTS(DISTINCT a.roles)) > 4 
RETURN TO_JSON_STRING(a.roles) AS r

Work with values and text

Dynamic nested data

Support for dynamic nested data lets queries work with richer values that do not fit a flat property model. This is useful when graph entities contain structured application payloads, nested attributes, or evolving schemas.

CAST

CAST converts a value to a supported target type. Explicit conversion makes comparisons and calculations more predictable when source data uses different numeric representations.

RETURN CAST(42 AS DOUBLE) AS double_res, 
 CAST(42 AS UINT) AS uint_res, 
 CAST(42.5d AS INT) AS int_res

RANGE

RANGE creates a numeric sequence. A generated sequence can support iteration, testing, bucketing, and list-oriented calculations within a query.

RETURN RANGE(0, 4) AS res

POWER

POWER performs exponent calculations. It extends the numeric expressions available for scoring, weighting, and mathematical transformations.

RETURN POWER(-2, 3) AS res

NORMALIZE and IS NORMALIZED

Unicode text can have visually identical but technically different encodings. NORMALIZE converts text to a normalization form, while IS NORMALIZED checks its current form. This supports more consistent matching and grouping across multilingual data.

RETURN NORMALIZE('cafe\u0301') AS normalized_text
RETURN 'cafe\u0301' IS NFKD NORMALIZED AS is_normalized

Regular-expression functions

The MSFT.REGEXP functions match, count, locate, extract, and replace text patterns. They help prepare identifiers, names, codes, and descriptions before those values are compared or summarized.

RETURN MSFT.REGEXP_LIKE('café', 'caf.') AS x
RETURN MSFT.REGEXP_COUNT('abcabcabc', 'abc') AS n
RETURN MSFT.REGEXP_INSTR('hello world', 'world') AS p
RETURN MSFT.REGEXP_REPLACE('a1b2c3', '[0–9]', '#') AS s
RETURN MSFT.REGEXP_SUBSTR('abc123def', '[0–9]+') AS s

Design guidance

Use the narrowest pattern that answers the question. Start from selective nodes, specify relationship and node labels, and apply filters early. Use bounded traversal when the business question has a natural maximum. When depth is unknown, combine an unbounded path with an appropriate path mode and test it against representative graph density. Return only the properties or path elements the application requires.

Feature availability can vary by environment and release stage. Confirm current support and syntax in the Microsoft Fabric Graph documentation before publishing a production query.

Next steps

Choose a connected-data scenario — such as lineage, dependency analysis, recommendations, investigations, or knowledge discovery — and identify which path, composition, and aggregation features make the question easier to express.

• Graph in Microsoft Fabric overview
• GQL language guide for graph in Microsoft Fabric
• GQL graph patterns
• GQL standard conformance for graph in Microsoft Fabric
• Optimize GQL query performance for graph in Microsoft Fabric

Tags: Graph, Graph Query Language (GQL), graph traversal, connected data, developers

Murilo Vasconcelos, Stefan Plantikow, Idris Motiwala, Eldad Hagashi, Qian Liang, Danny Navon, Michael Robson, Pau Baiget, Rajagopal Ravipati

More expressive graph analysis: GQL improvements in Microsoft Fabric Graph was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

As soon as an agent needs to touch the open internet — search, scrape, retrieve — “secure by design” stops being a slide and starts being an actual network problem.

This lab (aca-sandbox-foundry, an evolution of jkalis-MS/azure-container-apps-multi-agent-workflow) is a reference implementation for exactly that problem: an AKS-hosted, APIM-governed multi-agent system that isolates the one risky operation — web retrieval — inside disposable Azure Container Apps (ACA) Sandboxes, while everything around it stays authenticated, private, and observable.

Link to the repository and the full documentation journey at the bottom of this article.

What It Actually Does

The lab turns a single topic into a complete content package.

A Researcher agent gathers and synthesizes trusted sources into a research brief.

A Content Creator agent turns that brief into a long-form blog post and a social content package.

A Podcaster agent generates a multi-speaker script, synthesizes audio, and persists the result.

A browser-based DevUI shows the whole run: live agent health, sandbox lifecycle events, egress evidence, and the generated artifacts as they land.

Solution at a Glance

High-level architecture: the DevUI orchestrator, three framework-diverse agents, APIM, Foundry, Application Insights, and the ACA Sandbox retrieval path.

The user-facing orchestrator coordinates three framework-diverse agents on AKS. APIM governs both agent and model traffic, Microsoft Foundry supplies models and agent registration, Application Insights captures telemetry end to end, and ACA Sandboxes isolate only the research retrieval tool — the sandboxes never host the three long-running agents themselves.

Three Agents, Three Frameworks, One Contract

The lab intentionally refuses to treat every agent as “the same app in a different container.” Each one uses a distinct framework and runtime suited to its job, and A2A (Agent2Agent) is the common contract that lets them interoperate anyway — a real test of the protocol, not a convenience wrapper around one SDK.

DevUI is the user-facing orchestrator, but it is deliberately dumb about security: it runs the research step first, sends the resulting brief to the creator and podcaster in parallel, and never talks to an agent directly. Every call goes same-origin to the BFF, and every BFF call goes through APIM. No agent calls another agent — each remains an independently deployable service that happens to share an interoperability contract, not a tightly coupled pipeline.

The Azure Stack, Component by Component

This is where the lab earns its keep — not by picking exotic technology, but by wiring familiar Azure services together with a consistently paranoid network posture.

Azure Kubernetes Service (AKS)

AKS is the compute backbone for all three agents and the BFF. Each agent runs on a dedicated, tainted node pool, isolated from general workloads. No agent Pod is exposed publicly: every agent is fronted by an internal Kubernetes LoadBalancer Service bound to a private VNet address rather than a public IP. loadBalancerSourceRanges on each Service restricts inbound connections to APIM’s subnet alone, and Azure CNI powered by Cilium enforces the identical restriction a second time inside the cluster’s own dataplane. That redundancy is deliberate: even a bug in DevUI or the BFF that tried to call an agent directly, bypassing APIM, would find no route to take. AKS also hosts the Sandbox Broker, which is the only component permitted to request a sandbox on the Researcher’s behalf.

Azure API Management (APIM)

APIM is the single governed front door for two very different kinds of traffic, and that is the point: it is the only path in either direction. First, it fronts A2A traffic between the BFF and the three agents, so every inter-agent request is authenticated, rate-limited, and logged in one place rather than scattered across ad hoc service-to-service calls. Second, it exposes the /openai gateway that all three agents use for Microsoft Foundry model and text-to-speech access, so no agent holds a direct Foundry endpoint or API key of its own. Because APIM is also the only subnet allow-listed by every agent’s loadBalancerSourceRanges, it doubles as the network chokepoint the whole design is built around, not just an API facade.

Microsoft Foundry

Foundry is the model and agent-registration plane. It supplies the large language models the Researcher, Content Creator, and Podcaster call for synthesis, drafting, and script generation, along with the text-to-speech models behind the podcast audio. Foundry also handles custom-agent registration, giving each agent a governed identity in the platform rather than being an anonymous caller of a shared model endpoint. Every one of those calls is routed through the APIM /openai gateway — agents never dial Foundry directly, which keeps model access inside the same audit and policy boundary as every other governed call in the system.

Azure Container Apps (ACA) Sandboxes

Azure Container Apps Sandboxes reached general availability this week — and it is not a new isolation stack. It is Microsoft externalizing the same hardware-isolated microVM fabric that already runs Cloud Sandboxes in GitHub Copilot ,Foundry Hosted Agents, Azure ARE Agents and more. During public preview it was already creating over a million sandboxes a day. That maturity is exactly why it is the right foundation for the Researcher’s retrieval path in this lab, and for running private coding agents more broadly.

The GA announcement: sandboxes execute securely by default, resume instantly from a full memory-and-disk snapshot, and burst to hyperscale in sub-second time — with Azure Container Apps, Foundry, GitHub, and Container Apps Express all building on the same foundation layer.

The topology behind that announcement is straightforward once you see it laid out. A sandbox group is the unit of governance: everything inside it shares disk images, snapshots, data volumes, secrets, and identity, while every individual sandbox still gets its own CPU, memory, disk, and network boundary.

Portal, CLI, and SDK access all converge on a sandbox group. Ingress is off by default and opt-in per sandbox and port, waking on request; egress runs through a per-sandbox proxy enforcing host allowlists and deny policies, with injected credentials that never enter the sandbox itself.

That last point is the one worth sitting with: credential injection happens at the egress proxy, outside the sandbox boundary. Code running inside — including AI-generated code — never sees the actual secret, only the effect of a request that was allowed to go through. It is the same shape as the Sandbox Broker pattern in this lab’s Researcher path, just implemented as a first-class platform primitive instead of something you wire up yourself.

What This Looks Like Running

A sandbox group in the Azure portal shows exactly what it costs to keep isolation this granular: total sandboxes, how many are actually running versus stopped, custom images, and snapshots, alongside live runtime metrics for running cores and memory.

A live sandbox group: 4 total sandboxes (one goes down), running-core and running-memory metrics over the last days, and recent sandboxes each stopped with their exact resource footprint (4 cores / 8 GiB / 80 GiB, down to 0.25 cores / 512 MiB / 5 GiB) preserved for the next resume.

Scoping sandboxes per task, rather than sharing one long-lived environment, is the pattern that keeps retrieval contained. Here five sandboxes are each labeled with the single host they were created to reach — one for azure.microsoft.com, one for learn.microsoft.com, one for github.com, and so on — all created within the same second and all running on identical 1 core / 2 GiB / 20 GiB footprints.

Five sandboxes, each scoped to a single allow-listed host and spun up simultaneously — the sub-second, burst-to-hyperscale behavior from the GA announcement, seen from the inside.

And this is the observability piece made concrete: a single running sandbox, its live terminal, and its egress network traffic panel — every outbound request logged with a timestamp, method, destination, and an explicit allowed or denied verdict, right next to real-time CPU, memory, storage, and network utilization and a live log stream.

22 requests allowed, 0 denied — every GET call to azure.microsoft.com, learn.microsoft.com, files.pythonhosted.org, and pypi.org visible with its verdict, alongside live CPU, memory, storage, and network metrics for the sandbox.

This is what “governed, closed, and observable” means in practice: nothing leaves the sandbox that was not explicitly allow-listed, nothing that does leave is invisible, and none of it costs meaningful startup latency. For a Researcher agent fetching untrusted web content, or for a private Claude or GitHub Copilot coding agent running inside a customer’s tenant, that combination — hardware isolation, default-deny egress with full request-level audit, and sub-second start — is precisely the missing piece between “agents that browse the web” and “agents you can actually run in a governed enterprise environment.”

Now let’s return to our use case and see how ACA Sandboxes provides best solution for our needs.

ACA Sandboxes exist to solve one specific problem: the Researcher’s job requires fetching content whose provenance and payload it does not control, and that is the one operation in the whole system with real blast radius. The Researcher never performs that fetch itself — it hands the task to a Sandbox Broker, which spins up a short-lived, per-task ACA Sandbox with default-deny egress (in our example we blocked bing.com on purpose), scoped to exactly the destinations that single task requires. When the task completes, the sandbox is torn down with it. If a scraped page tried to phone home or pivot toward an internal service, there would be nothing left for it to reach by the time anyone noticed. Sandboxes are strictly a retrieval tool for the Researcher — they never host the long-running agents, the BFF, or DevUI.

Identity, Storage, and Observability

A user authenticates through Microsoft Entra ID, fronted by Application Gateway for Containers and an OAuth2 Proxy sidecar pattern, so no credential — reusable or otherwise — ever lives in the browser. The Podcaster writes generated audio to private Azure Blob Storage using Workload Identity instead of a connection string or access key in a config file. And OpenTelemetry instrumentation runs through every agent and the BFF, exporting to Application Insights and Log Analytics with APIM diagnostics stitched into the same correlation IDs, so a slow or failed run can be traced end to end — from the browser click down through the sandbox that did the retrieval.

Seeing It Run: User Experience

How a Request Actually Flows

1. A user authenticates with Microsoft Entra ID through Application Gateway for Containers and OAuth2 Proxy.

2. DevUI JavaScript calls same-origin protected APIs through the BFF.

3. The BFF sends A2A requests to APIM rather than exposing reusable downstream credentials in the browser.

4. APIM reaches three source-restricted private AKS origins: research, creator, and podcaster.

5. The agents use the APIM /openai gateway for Foundry model and TTS access.

6. Research delegates isolated retrieval to the Sandbox Broker, which creates policy-controlled ACA Sandboxes.

7. Podcaster persists audio through a private Blob endpoint, while workloads and APIM export correlated telemetry to Application Insights.

Project Status and Deployment Boundary

This is a working baseline, not a proof of concept: AKS, APIM, Foundry, ACA Sandboxes, private storage, identity, ingress, and observability are all deployed and validated together as a conventional Kubernetes stack, stood up end to end with the Azure Developer CLI and Bicep.

One caveat worth flagging for anyone adapting this: the demonstration AKS API endpoint is left public for operator convenience, while the application workloads and agent origins themselves stay private. A production deployment needs a private AKS control plane, trusted TLS, production-grade identity governance, and organization-approved network controls layered on top of everything described above.

Summary

The interesting decision in this lab is not “agents can collaborate” — that part is easy to demo and easy to fake. It is that the one operation with real blast radius, unrestricted web retrieval by an LLM-driven agent, is fully contained behind default-deny, per-task sandboxes, enforced at two independent layers of the network, while the rest of the system stays governed by Entra ID, APIM, and Foundry end to end.

Resources and documentation

● Repository: lyantovski/aca-sandbox-foundry

● Azure Container Apps Sandboxes, Now Generally Available | Microsoft Community Hub

● ACA Sandboxes | ACA Sandboxes Portal Docs

Building a Governed Multi-Agent Content Factory on Azure was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tip #1 — Foundry-hosted agents and outbound traffic

When hosting your agents in Foundry, they are running into a container app environment managed by Microsoft behind the scenes. While Foundry supports the BYO subnet feature, you must make sure to:

• Use a standard setup (not basic)
• Bring not only your own subnet but also your own resources, meaning Cosmos DB, AI Search, Storage, etc.

Only bringing your own subnet will not throw any error but the agents will still fail to resolve private link resources and go to the public endpoints of any resource they try to reach.

Here is a useful repo to get started https://github.com/microsoft-foundry/foundry-samples/

Tip #2 — Using private link with Sandbox Groups

Azure Sandbox Groups are a great way to execute LLM-generated code safely. They are backed by MicroVMs, ensuring strict isolation as well as lightning speed. However, in the enterprise environment, we tend to isolate things from internet as much as possible, and here comes the tip! Sandbox Groups themselves have no private endpoints. The best you can achieve is to add network ACLs on their public endpoints. However, you can attach them to Container Apps Environments of type ‘Express’. Once attached, the Sandbox Groups can be connected using private endpoints. You can read more about this here https://sandboxes.azure.com/docs/sandboxes/private-endpoints

Tip #3 — Dealing with MCP authentication (DCR and/or CIMD)

I shared a few options to deal with MCP within the Azure and Microsoft ecosystem. You can read this here to get all the details https://medium.com/@stephaneeyskens/i-built-my-own-wine-companion-mcp-server-on-azure-and-net-it-wasnt-that-straightforward-f8e74fab8722 .

However, I recently discovered an option I wasn’t aware of, consisting of using FastMCP, a Python library. In a nutshell, FastMCP is a library that is part of your MCP server and acts as a proxy between the MCP client and your MCP server.

It supports both Dynamic Client Registration (DCR) and Client ID Metadata Documents (CIMD). During the handshake, the client communicates with FastMCP rather than directly with the identity provider for registration and token acquisition. The client interacts with Entra ID only to authenticate the user.

FastMCP acquires tokens transparently and passes them to the MCP server, which can then use an on-behalf-of (OBO) flow to obtain tokens for downstream APIs. FastMCP also provides a state API that makes it easier to persist state in Redis, using a computed JTI key to link that state to upstream tokens.

Below is the sequence diagram showing the flow.

Here is a pointer to the official FastMCP web site https://gofastmcp.com/v2/servers/auth/oauth-proxy

Tip #4 — Dealing with MCP integration with SaaS platforms

Although Satya Nadella suggested that SaaS platforms would die with the rise of AI, we still see many SaaS platforms whose the core business is AI. Platforms such as Perplexity and Claude code are just examples of these. I see two ways to expose your enterprise MCP servers to the outside world:

• Use Private Link Service (PLS) whenever possible if the SaaS provider supports it.
• Expose your MCP server to Internet. In this case, you’d go for Front Door/Application Gateway ==> API Management ==> MCP server with or without FastMCP.

However, at this stage, using PLS remains not that easy because:

• As of 09/2026, PLS Direct Connect is still in preview and only available in a few regions (e.g. only Spain Central for Europe).
• The destination of a PLS cannot be a private endpoint, although it technically works (I tested it).

The Citadel approach consists in using an AI gateway (API Management) as a central policy enforcement point. However, as of 09/2026, we cannot use Private Link Service (PLS) with API Management’s load balancer because PLS does not recognize it as an Azure Load Balancer. A private endpoint for APIM might seem like an alternative, but that scenario is not supported either. PLS requires a standard Azure Load Balancer, such as the one used by AKS.

For now, the only supported approach appears to be proxying the AI gateway through a gateway API hosted on AKS, although that feels like a dirty workaround. Hopefully, Microsoft will make PLS Direct Connect generally available across all regions soon and support private endpoints as destinations, enabling a wider range of integration scenarios.

Tip #5 — Writing stateful agents

There are many ways to orchestrate agents, but fewer options for running stateful orchestrations. As of 09/2026, I consider Dapr workflows to be one of the best options. Additionally, Dapr makes it easy to run ambient agents, which are nothing else but agents responding to events/commands, and Dapr particularly excels in building distributed systems.

Sharing a few tips and tricks about AI on Azure, that Claude itself isn’t always aware of! was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

As organizations build more AI powered applications, choosing the right model for every request becomes increasingly important. Not every prompt requires a large and expensive reasoning model, while more complex workloads often benefit from advanced models with higher capabilities. Microsoft Foundry Model Router addresses this challenge by automatically selecting the most appropriate model for each request based on factors such as complexity, quality requirements, latency, and cost. Instead of maintaining custom routing logic, developers can interact with a single endpoint while the routing decisions happen behind the scenes..

In this article, we will deploy Microsoft Foundry Model Router using Bicep and explore how Infrastructure as Code can simplify the deployment and management of intelligent AI routing workloads on Azure.

The main.bicepparam template defines our input parameters, such as the Landing Zone, Environment, Location.

using 'main.bicep'

//////////////////////////////////
param parAlzName = 'sln'
param parEnvironment = 'prod'
param parLocation = 'swedencentral'
/////////////////////////////////

The main.bicep template serves as the entry point for our Bicep configuration and defines the parameters and variables used across the Azure AI Foundry module.

metadata name = 'Cognitive Services Account with Model Router'
metadata description = 'This is a Bicep template to deploy a Cognitive Services Account with the Model Router deployment.'
metadata owner = 'Brian Veldman'
metadata version = '1.0.0'

/* TARGET SCOPE */
targetScope = 'subscription'

@description('Defining our input parameters')
param parEnvironment string
@allowed([
  'swedencentral'
])

param parLocation string 
param parAlzName string

@description('Defining our variables')
var shortEnvironmentMapping = {
  swedencentral: 'sdc' // Supported for Model Router in Foundry
}

var shortEnvironment = shortEnvironmentMapping[parLocation] ?? parLocation
var resourceGroupName = 'rg-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'

@description('Deploying our resourcegroup')
resource rg 'Microsoft.Resources/resourceGroups@2025-04-01' = {
  name: resourceGroupName
  location: parLocation
}

@description('Deploying our AI module')
module ai 'modules/ai.bicep' = {
  params: {
    parAlzName: parAlzName
    parEnvironment: parEnvironment
    parLocation: parLocation
    shortEnvironment: shortEnvironment
  }
  scope: rg
}

The ai.bicep module automates the deployment of an Azure AI Foundry environment by provisioning an Azure AI Services account, an AI Foundry project, and a Model Router deployment. It creates a centrally managed AI platform with project management capabilities enabled, configures a dedicated AI Foundry project with a system assigned managed identity for secure resource access, and deploys a Model Router endpoint using the Global Standard SKU. The module also applies a consistent naming convention based on the landing zone, environment, and location parameters, enabling standardized and scalable AI service deployments across Azure environments. ❤️

param parEnvironment string
param parLocation string 
param parAlzName string
param shortEnvironment string

@description('Deployment of Foundry')
resource aif 'Microsoft.CognitiveServices/accounts@2025-12-01' = {
  name: 'aif-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'
  location: parLocation
  kind: 'AIServices'
  sku: {
    name: 'S0'
  }
  properties: {
    allowProjectManagement: true
    customSubDomainName: 'sub-aif-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'
  }
}

@description('Deployment of Foundry Project')
resource aip 'Microsoft.CognitiveServices/accounts/projects@2025-12-01' = {
  name: 'proj-aif-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'
  parent: aif
  location: parLocation
  identity: {
    type: 'SystemAssigned'
  }
}

@description('Deployment of Foundry Model Router')
resource router 'Microsoft.CognitiveServices/accounts/deployments@2025-12-01' = {
  name: 'model-router'
  parent: aif
  sku: {
    name:  'GlobalStandard'
    capacity: 499 //1 capacity unit = 1000 tokens per minute, took the standard capacity
  }
  properties: {
    model: {
      name: 'model-router'
      format: 'OpenAI'
      version: '2025-11-18' // Last supported version
      
    }
    routing: {
      mode: 'balanced'
    }
  }
}

Customize the code to align with your specific requirements, then execute it. After a few minutes, all the necessary resources will be deployed. This can be done using: New-AzSubscriptionDeployment -Name deploymentName -TemplateFile .\main.bicep -TemplateParameterFile .\main.bicepparam -Location swedencentral.

After deployment, you can use the standard Chat Completions API against the Model Router endpoint. Simple prompts are typically routed to smaller and cheaper models, while more complex reasoning tasks are automatically directed to larger models. This allows organizations to optimize both cost and performance without modifying application logic.

Within the Microsoft Foundry portal, navigate to Deployments and verify that the Model Router deployment is present and successfully provisioned.

We can see the model-router deployment. For this demo, I will use the Open in Playground option, which allows us to test the Model Router directly from within the browser.

When I ask “What is Azure?”, the request is routed to the GPT-5 Mini model by the Model Router, which selects the most appropriate model based on the prompt and routing configuration. For this query, the GPT-5 Mini model is chosen to generate the response.

However, when I ask, “Can you write an Azure Bicep template based on Azure Verified Modules to deploy an Azure Virtual Machine?”, the Model Router selects the GPT-5.3 Chat model. This is because the request involves more advanced reasoning, code generation, and knowledge of Azure infrastructure patterns, making GPT-5.3 Chat the more suitable model for generating an accurate and comprehensive response.

We can also use the Completions API to call the Model Router endpoint directly. With this approach, every request is automatically routed to the most suitable model based on the complexity and requirements of the prompt. This allows applications to benefit from optimized model selection without having to manually choose between different models, helping to balance performance, capability, and cost.

That’s all for today. As you could see, Azure AI Foundry Model Router simplifies the way applications interact with AI models by automatically selecting the most suitable model for each request. Whether you are handling simple questions, complex reasoning tasks, or code generation scenarios, Model Router helps optimize performance, capability, and cost without requiring manual model selection. This makes it easier to build intelligent applications that can adapt to a wide range of user requests while taking full advantage of the latest AI models available in Azure AI Foundry. The Azure Bicep code is available in my GitHub repository: GitHub — brianveldman/azure-bicep. Feel free to star the repository and clap for this story and let me know if you have any feedback. I look forward to seeing you in the next session. Until then, take care! ❤️

Deploy and use the Foundry Model Router using Azure Bicep was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I started blogging, one of my first articles was about configuring Microsoft Entra ID authentication for Azure SQL Database. At that time, everything was done manually through the Azure portal using ClickOps. While that worked perfectly fine, it wasn’t exactly the Infrastructure as Code approach that I prefer. Recently, I was asked how to deploy Azure SQL with Microsoft Entra ID authentication entirely using Azure Bicep. That question inspired me to revisit the topic and build a fully automated solution that not only deploys the Azure SQL Server and database, but also creates the required Microsoft Entra groups and configures the Entra administrator. In this blog, I’ll walk you through building a complete end to end Azure Bicep solution, allowing you to provision Azure SQL with Microsoft Entra ID authentication from scratch without relying on manual configuration in the Azure portal.

The main.biceptemplate serves as the entry point for our Infrastructure as Code solution. It defines the parameters, variables, and module orchestration required to deploy the complete Azure SQL environment.

metadata name = 'Deploy Azure SQL Server with Entra ID Authentication'
metadata description = 'Deploys an Azure SQL Server with Entra ID authentication enabled for administrators.'
metadata owner = 'Brian Veldman'
metadata version = '1.0.0'

/* TARGET SCOPE */
targetScope = 'subscription'
/* EXTENSIONS */
extension 'br:mcr.microsoft.com/bicep/extensions/microsoftgraph/v1.0:0.1.8-preview'

@description('Defining our input parameters')
@allowed([
  'canadacentral'
  'westus'
  'westus2'
  'eastus'
  'eastus2'
  'westeurope'
])
param parLocation string = 'canadacentral'
param parEnvironment string
param parAlzName string

@description('Defining our variables')
var varShortEnvironmentMapping = {
  canadacentral: 'cnc'
  westus: 'wus'
  westus2: 'wus2'
  eastus: 'eus'
  eastus2: 'eus2'
  westeurope: 'weu'
}

var shortEnvironment = varShortEnvironmentMapping[parLocation] ?? parLocation
var resourceGroupName = 'rg-sql-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'
var sqlServerName = 'sql-entra-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'
var sqlDatabaseName = 'sqldb-test-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'

@description('Resource Group Deployment')
resource sqlResourceGroup 'Microsoft.Resources/resourceGroups@2023-07-01' = {
  name: resourceGroupName
  location: parLocation
}

@description('Creating Entra ID Group for SQL Administrators')
resource groupAdministrators 'Microsoft.Graph/groups@v1.0' = {
  displayName: 'SQL Administrators'
  mailEnabled: false
  mailNickname: 'sqladministrators'
  securityEnabled: true
  uniqueName: 'sqladministrators'
  members: [
    deployer().objectId
  ]
}

@description('Creating Entra ID Group for SQL Readers')
resource groupReaders 'Microsoft.Graph/groups@v1.0' = {
  displayName: 'SQL Readers'
  mailEnabled: false
  mailNickname: 'sqlreaders'
  securityEnabled: true
  uniqueName: 'sqlreaders'
}

@description('Deploying Azure SQL Server with Entra ID Authentication')
module server 'br/public:avm/res/sql/server:0.21.3' = {
  params: {
    name: sqlServerName
    administrators: {
      azureADOnlyAuthentication: true
      login: groupAdministrators.displayName
      principalType: 'Group'
      sid: groupAdministrators.id
    }
    location: parLocation
    databases: [
      {
        name: sqlDatabaseName
        availabilityZone: -1
        collation: 'SQL_Latin1_General_CP1_CI_AS'
        maxSizeBytes: 53687091200
        zoneRedundant: false
        sku: {
          name: 'S1'
          tier: 'Standard'
        }
      }
    ]
  }
  scope: resourceGroup(resourceGroupName)
  dependsOn: [
    sqlResourceGroup
  ]
}

Customize the code to align with your specific requirements, then execute it. You can do this by using: New-AzSubscriptionDeployment -Name deploymentName -Location canadacentral -TemplateFile .\main.bicep. After a few minutes, all the necessary resources will be deployed. We can see the Azure resources deployed within the resource group.

When checking Microsoft Entra ID, we can see that the SQL Administrators group has been created successfully, with me added as a member through the deployer().objectId function, which is exactly the expected behavior.

We can also see that the SQL Administrators Microsoft Entra ID group has been configured as the Microsoft Entra administrator for the Azure SQL Server. 😍

Now using the Query Editor we can access the Azure SQL Database since we have succesfully access to it using the Microsoft Entra Authentication.

What about the SQL Readers group? For this group, I chose to create the Microsoft Entra ID group as part of the Bicep deployment. However, I grant it access manually by using the following T-SQL statement to create the contained database user: CREATE USER [SQL Readers] FROM EXTERNAL PROVIDER;

We can also grant the SQL Readers group the db_datareader database role by using the following T-SQL statement: ALTER ROLE db_datareader ADD MEMBER [SQL READERS];. From now on, any user who is added to the Microsoft Entra ID group SQL Readers can connect to the Azure SQL Database using SQL Server Management Studio, provided they have network access to the database. Because the group is a member of the db_datareader role, its members can read data from all user tables and views in the database.

From this point, you know how to deploy an Azure SQL environment by using Azure Bicep and securely grant users access to Azure SQL databases through Microsoft Entra ID authentication. By adopting Infrastructure as Code, you can build repeatable, scalable, and consistent Azure SQL environments while minimizing manual configuration, reducing deployment time, and improving security. The Azure Bicep code is available in my GitHub repository: GitHub — brianveldman/azure-bicep. Feel free to star the repository and clap for this story. That’s all for today. I’d love to hear your feedback, and I look forward to our next session. Until then, take care. ⭐️

Configuring Microsoft Entra ID Authentication for Azure SQL Database using Azure Bicep was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

A vessel is crossing the Strait of Hormuz. Its AIS signal updates in real time. A few minutes later, the vessel enters a high-risk zone.

For a maritime insurer, that single movement can trigger a chain of business questions:

Is the vessel still covered?
Does the policy include a war-risk exclusion?
Is there a warranty breach?
Which company operates the vessel?
What cargo is onboard?
What is the financial exposure right now?

Traditionally, answering those questions requires people to stitch together multiple systems: live vessel telemetry, geospatial boundaries, policy contracts, customer and cargo data, dashboards, and operational alerts.

This is exactly the kind of problem where enterprise AI needs more than retrieval. It needs business context.

In this post, I’ll show how I built a maritime risk “Company Brain” on Microsoft Fabric: an ontology-driven AI experience that connects live operational signals, semantic business relationships, and trusted policy documents so a Fabric Data Agent can answer risk questions in real time.

The disconnect between dynamic risk and static rules

Maritime insurance risk is constantly changing. A vessel’s location, speed, route, AIS status, nearby weather, cargo, and geopolitical exposure can all shift while the policy language governing that risk remains locked inside static PDF or Word documents.

That creates a practical gap for underwriters and risk analysts.

They may have the data, but the meaning is scattered across different systems:

- live AIS telemetry
- geospatial risk boundaries
- policy contracts and warranty clauses
- vessel, company, cargo, and policy master data
- analytical dashboards and operational alerts

Each system can answer part of the question. None of them, on its own, can answer the business question that matters:

Is this vessel exposed right now, what does the policy say, and what should we do about it?

That is the gap this demo is designed to close.

The solution: a geospatial Company Brain

The core idea behind the demo is simple: the AI agent should not guess, and it should not treat every question as a document search problem.

Instead, it should understand which source of knowledge is responsible for each part of the answer.

In this solution, Microsoft Fabric becomes the foundation for a maritime risk Company Brain: a connected intelligence layer that combines live vessel state, geospatial risk context, business relationships, and trusted policy language.

The result is an AI experience that can answer business questions such as:

- Where is this vessel right now?
- Is it inside a high-risk zone?
- Which company operates it?
- What cargo is it carrying?
- Which policy applies?
- What does the policy say about this situation?
- Is there a coverage issue or warranty breach?
- What action should the risk team take?

That is the shift: from a dashboard that shows live data to an agent that explains what live data means for the business.

High-level architecture

End-to-end architecture for the maritime risk Company Brain, built with Microsoft Fabric and Azure AI Search.

The architecture is centered on Microsoft Fabric, with Azure AI Search connected as the external knowledge retrieval layer for policy documents.

At a high level, the flow works like this:

1. Live AIS telemetry is received from AisStream.io and published into Fabric Eventstream.
2. Eventhouse stores the real-time vessel stream and uses KQL functions, update policies, and materialized views to enrich each position with geospatial risk context.
3. Lakehouse stores the business master data: vessels, companies, cargo, policies, and maritime risk zones.
4. GeoJSON risk-zone files define polygons such as Red Zone and Yellow Zone boundaries. These are transformed into structured tables that Eventhouse can use for geospatial enrichment.
5. Power BI semantic model and Fabric ontology describe the business relationships between vessels, operators, cargo, policies, and live vessel position.
6. Azure AI Search indexes policy documents so the agent can retrieve coverage, exclusion, warranty, deductible, and war-risk language.
7. Fabric Data Agent orchestrates the answer by routing each part of the question to the right source.
8. Fabric Map and Activator provide the visual and operational layers: live geospatial monitoring and alerting when a vessel enters a critical zone.

The key design choice is the vessel entity. The vessel, identified by MMSI, becomes the bridge between the operational world and the business world. Its latest position comes from Eventhouse, while its operator, cargo, policy, and coverage context come from the semantic model and ontology.

That lets the Data Agent answer questions that require both real-time state and business meaning.

How the solution works

After the architecture is in place, the implementation follows a simple flow: ingest live vessel telemetry, enrich it with geospatial risk context, connect it to business entities, and ground policy answers in indexed documents.

The live vessel data comes from AisStream.io, which provides a high-frequency feed of real-world AIS telemetry broadcast by ships across the world’s oceans. Each vessel is identified by an MMSI, or Maritime Mobile Service Identity: a unique 9-digit identifier that works like a digital license plate for a ship. In this solution, MMSI is the key that connects live telemetry in Eventhouse to the vessel entity in the ontology.

A Fabric notebook connects via WebSocket to AisStream.io and publishes live AIS events into Fabric Eventstream. Eventstream lands the telemetry in Eventhouse, where the raw maritimeAIS table stores vessel position, speed, heading, MMSI, ship name, and ingestion time.

Inside Eventhouse, KQL functions enrich each incoming position with geospatial risk context. The solution evaluates whether a vessel is inside a defined polygon using geo_point_in_polygon, then adds fields such as IsInZone, ZoneName, RiskLevel, and PremiumMultiplier. The enriched stream is stored in maritimeAIS_Enriched.

To make current-state questions fast and reliable, the solution creates the LatestShipPositionsEnriched materialized view. This view keeps only the most recent enriched position for each vessel, keyed by MMSI.

In parallel, the Lakehouse stores the business master data: vessels, companies, cargo, policies, and maritime risk zones. The risk zones are defined as GeoJSON files, transformed into a structured maritimezones table, and used by Eventhouse for geospatial enrichment.

The semantic model and Fabric ontology then connect the vessel to the business context around it: operator, cargo, policy, and latest live position.

Finally, policy documents are indexed in Azure AI Search so the Data Agent can retrieve relevant language about coverage, exclusions, warranties, deductibles, and war-risk conditions.

Together, these components allow the agent to move from a live vessel position to a business-level risk answer: where the vessel is, whether it is inside a risk zone, who operates it, what cargo it carries, which policy applies, and what the policy says about the current situation.

Why Ontology matters

One of the most important lessons from this demo is that enterprise AI needs more than retrieval.

RAG is powerful, but document search alone does not know which document matters. A policy clause may look relevant, but the agent still needs to know which policy belongs to which vessel, who operates that vessel, what cargo it carries, and whether the vessel is currently inside a risk zone.

That is where the ontology becomes critical.

In this architecture, the vessel is the central business entity. It connects the real-time operational world to the business and contractual world:

- latest vessel position from Eventhouse
- operator from the company master data
- cargo from the cargo master data
- policy from the insurance master data
- risk-zone status from geospatial enrichment

For example, if a user asks:

Is EAST_SIMULATED_TANKER_02 covered while crossing the Red Zone?

The agent should not start by searching all documents. It should reason through the business graph:

1. Find the vessel’s latest location in Eventhouse.
2. Check whether IsInZone is true and identify the RiskLevel.
3. Resolve the vessel to its company, cargo, and policy through the ontology.
4. Retrieve the relevant policy clauses from Azure AI Search.
5. Synthesize a grounded answer.

This is the difference between an AI assistant that can search and an AI agent that can understand context.

Building the Data Agent

The Fabric Data Agent is the orchestration layer for the experience.

In this demo, the agent is grounded in three complementary sources of knowledge:
- Eventhouse answers live operational questions: where the vessel is, whether it is inside a risk zone, and what the current risk state is.
- Fabric ontology and semantic model answer business-context questions: who operates the vessel, what cargo it carries, and which policy applies.
- Azure AI Search answers policy-evidence questions: what the insurance documents say about coverage, exclusions, warranties, deductibles, and war-risk conditions.

If the user asks where a vessel is, the agent should use Eventhouse.
If the user asks who owns a vessel or which policy applies, it should use the ontology.
If the user asks whether something is covered, excluded, or subject to a deductible, it should use Azure AI Search.
For complex questions, it should chain all three.

For example:

Is MV Ocean Voyager covered for a drone strike right now?

The expected reasoning path is:

1. Query LatestShipPositionsEnriched to find the vessel’s current location and zone status.
2. Use the ontology to find the policy linked to that vessel.
3. Search the policy index for drone strike, war exclusion, and high-risk zone language.
4. Return a grounded answer that cites both the live zone and the relevant contract clause.

The important point is that the agent is not inventing geospatial boundaries or legal interpretations. It is grounded in the live KQL materialized view, the ontology, and the indexed policy documents.

Real-time risk in action

For the demo, I used both real AIS data and simulated vessels.

The real AIS stream demonstrates live ingestion into Eventhouse. The simulation notebooks create controlled vessel itineraries that intentionally cross defined risk zones, which makes it easier to demonstrate how the risk state changes over time.

Two simulated vessels are included:

- SIMULATED_TANKER_01
- EAST_SIMULATED_TANKER_02

Each simulated vessel is enriched with demo insurance context such as company, cargo, hull value, and policy ID. One vessel is associated with a Hull & Machinery policy, while another is associated with a War Risk policy.

As the simulated vessels move through the Strait of Hormuz scenario, the Data Agent’s answers change.

When a vessel is outside a risk zone, the agent can report standard coverage and no active breach. When the same vessel enters the Red Zone, the agent can flag elevated exposure, identify the critical zone, apply the premium multiplier, retrieve the relevant policy language, and explain the potential warranty or coverage impact.

This is the key experience: the same business question receives a different grounded answer because the operational reality changed in real time.

That is what makes the pattern powerful. The agent is not just answering from static knowledge; it is reasoning over the current state of the business.

Visualizing live maritime risk with the Fabric Map item

The Fabric Map item provides the spatial operating picture for the demo.

While the Data Agent answers natural-language business questions, the map lets users see the same risk scenario visually: live vessels moving across geographic boundaries, risk-zone polygons, and changing exposure over time.

In this solution, the map brings together three layers:

- live vessel positions from Eventhouse
- maritime risk-zone polygons from Lakehouse GeoJSON data
- business context from the ontology, where each vessel connects to operator, cargo, policy, and current location

This is especially useful for real-time risk monitoring. An underwriter can inspect vessels approaching a high-risk polygon, filter by operator or cargo type, zoom into a corridor such as the Strait of Hormuz, and then ask the Data Agent a grounded follow-up question about coverage, warranties, or financial exposure.

In other words, Fabric Map provides the spatial view, while the ontology and Data Agent provide the business meaning behind what the user sees.

From dashboard to decision

Dashboards are still valuable. They show what is happening.

But the Data Agent adds a different interaction model. It helps users ask what the situation means.

A dashboard can show that a vessel is in a particular location. An ontology-driven agent can connect that location to the vessel’s operator, cargo, policy, current risk zone, and relevant contractual language.

That distinction matters for underwriters and risk teams. They do not only need to see that something happened; they need to understand whether it creates a coverage issue, whether the cargo changes the severity, whether the operator has a high-risk profile, and whether the policy includes a relevant exclusion or warranty condition.

With the ontology-driven approach, the agent can connect those dots and turn live telemetry into a business-level risk explanation.

Adding operational alerts with Activator

The solution also includes an Activator scenario, represented in the repository as a Reflex item called RedAlertActivator.

This adds an operational layer to the pattern. Once live data is enriched with geospatial and business meaning, it can trigger action rather than only support analysis.

For example, when a vessel enters a critical zone, the system can move beyond passive monitoring and activate an alerting flow.

That creates a practical enterprise pattern:

1. Eventstream ingests live data.
2. Eventhouse enriches the data in real time.
3. Materialized views expose the latest risk state.
4. Power BI and Fabric Map visualize the fleet.
5. Data Agent explains the business meaning.
6. Activator triggers operational action.

This is where the Company Brain becomes more than a question-answering interface. It becomes part of the operating model.

Example questions for the Data Agent

Here are some of the prompts I used to demonstrate the solution:

Where is SIMULATED_TANKER_01 right now, and is it in a risk zone?

What is the total risk assessment for EAST_SIMULATED_TANKER_02?

Is this vessel in breach of any policy warranty?

Which of my ships are currently inside a high-risk zone?

What does the policy say about war-risk zones for this vessel?

Who operates this vessel, what cargo is it carrying, and which policy applies?

These prompts demonstrate different agent behaviors.

Some are pure live telemetry questions. Some are ontology traversal questions. Some are policy retrieval questions. The most interesting ones require the agent to orchestrate all three.

What I learned building it

The biggest learning from this demo is that the value of enterprise AI does not come only from the model.

It comes from grounding the model in the right architecture.

A strong enterprise AI architecture needs:

Live operational context

For this demo, that context came from AIS telemetry streaming through Eventstream into Eventhouse.

Semantic business context

The ontology gave the AI a way to understand relationships between vessels, companies, cargo, policies, and zones.

Trusted knowledge

Azure AI Search gave the agent access to policy documents and legal clauses without forcing the user to manually read through dense contracts.

Clear routing and orchestration

The Data Agent needed explicit instructions about when to use Eventhouse, when to use the ontology, and when to use AI Search.

Real-time state

The LatestShipPositionsEnriched materialized view was essential because risk assessment depends on the latest vessel position, not historical telemetry.

Together, these pieces create something much more useful than a generic chatbot.

They create an AI agent that can reason over the business.

Why this pattern matters

Although this demo focuses on maritime insurance, the pattern applies to many industries.

In manufacturing, the central entity might be a machine or production line.

In healthcare, it might be a patient journey.

In retail, it might be a product, supplier, or store.

In energy, it might be an asset, grid node, or maintenance event.

The common pattern is the same:

1. Capture live operational signals.
2. Enrich them with domain-specific logic.
3. Model business entities and relationships.
4. Ground the AI in trusted documents.
5. Expose the experience through a natural-language agent.
6. Trigger alerts or actions when business conditions change.

That is the essence of the Company Brain.

It is not just an AI assistant connected to data. It is an AI layer that understands how the business is connected.

Final thoughts

The Fabric IQ demo at the Microsoft AI Tour was a great opportunity for me to show how Microsoft Fabric can bring together real-time analytics, semantic modeling, ontology, document intelligence, and AI agents into a single architecture.

The most exciting part is the shift in user experience.

Instead of asking analysts to manually inspect telemetry, dashboards, policies, and risk rules, we can let them ask business questions directly:

“Which vessels are exposed right now, why, and what does the policy say?”

That is the promise of ontology-driven AI.

When your data platform understands your business entities, your AI agent can do more than retrieve information. It can reason across live events, business relationships, and trusted knowledge.

That is how we start building the Company Brain.

Resources

The full demo repository is available here:

https://github.com/dorirabin/fabricdemo/tree/fabriciq-maritimedemo

The repo can be automatically deployed in your Fabric Workspace using the fabric cicd python library
The full demo repository includes the Fabric assets, notebooks, ontology, Data Agent configuration, sample policy documents, reports, maps, and Activator scenario used to build the solution.

From Live Signals to Smarter Risk: Building a Company Brain on Microsoft Fabric was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.