Wednesday, October 21, 2026 Daily Edition
Data Dive Daily

DISPATCHES FROM THE MICROSOFT AI ECOSYSTEM

9 min read

Azure Foundry, Zero Trust, and SASE for AI Agents

This post walks through a video session by enterprise architect Hallowell M. Longley, "Agentic AI Architecture" (youtu.be/IcEqtjrhyB0). It covers Microsoft Foundry, Zero Trust, and SASE, and how they fit together when you run AI agents at scale. The main idea is simple. The old security perimeter is mostly gone. Agents now run across many clouds, so you need one place to build and manage them, and one set of security rules that follows them. This post does not cover pricing, licensing, or setup steps. I checked the session's Foundry claims against Microsoft Learn

Foundry puts the AI pieces in one place

Microsoft Foundry has had three names. It was Azure AI Studio, then Azure AI Foundry, and it is now Microsoft Foundry ( learn.microsoft.com/azure/foundry/what-is-foundry ). The Azure resource type is still Microsoft.CognitiveServices/accounts, so you will see older names in templates and scripts.

Teams used to keep vector databases in one console, models in another, and security policies spread across subscriptions. Foundry brings agents, models, evaluation tools, and data under one Azure resource provider namespace. That gives you three useful things in one place: role-based access control (RBAC), private endpoints for networking, and Azure policy. Tracing and live evaluation also sit inside the developer workflow, so you can see problems while you build.

Your tools stay the same. You can work from Copilot Studio, Visual Studio, GitHub, or the Foundry SDK. Underneath, they use the same services: Foundry models, Foundry Agent Service, Azure AI Search, Azure Machine Learning, and Azure AI Content Safety. Governance covers cloud, edge, and hybrid setups through Azure Arc.

Two control planes

Data comes in from SharePoint, enterprise data lakes, Azure Databricks, and Fabric IQ. Inside Foundry, these pieces work together:

The session also lists Redis semantic caching. That one is not a Foundry feature. You add it yourself, either in application code or with API Management policies, using Azure Managed Redis as the cache ( learn.microsoft.com/azure/redis/tutorial-semantic-cache ).

The session spends most of its time on governance. Foundry splits it into two planes, and each one answers a different question.

  • Foundry Control Plane: answers "Is the agent running well and safely?" It covers fleet inventory, traces, error rates, token use and cost, guardrail policies, and Defender and Microsoft Purview alerts.
  • Agent 365: answers "Is the agent allowed to act?" It covers authorization, compliance, Microsoft 365 and Entra identity policy, and user-facing channels like Teams and Copilot.

In a mature setup, both planes run at the same time. An agent can be fast, cheap, and fully traced, and still not be authorized. That is why you need both.

One detail the session leaves out is worth knowing. Agent 365 is a Microsoft 365 service. Foundry sends it no data until your tenant has an Agent 365 license and a global administrator has accepted its terms ( learn.microsoft.com/azure/foundry/agents/concepts/agent-365-integration ). After that, Foundry registers its agents there automatically.

Running hundreds of agents

One generative AI pilot is easy to watch. Hundreds of agents across several teams take more structure. The Foundry Control Plane groups that work into five areas:

  • Fleet management: find, catalog, and register every agent in the organization
  • Observability: distributed tracing, model evaluations, and latency and token numbers
  • Compliance: regulatory controls, guardrails, and enterprise policy
  • Security: identity boundaries and credential isolation, so an agent can't raise its own privileges
  • Access management: who can deploy, change, or use which agent

It connects to Microsoft Defender for threat detection, Microsoft Purview for data governance and sensitivity labels, and Microsoft Entra for privileged identity access.

The session also says the control plane covers agents on third-party platforms. That is only partly true. The docs show it finds Foundry agents, Azure SRE Agent, and Azure Logic Apps agent loops on its own. For anything else, you register the agent by hand as a custom agent. Custom agents get less control. You can block or unblock requests to them, but not start or stop them, and traces need extra instrumentation in the agent's own code. Classic Foundry agents and Azure OpenAI assistants are not supported ( learn.microsoft.com/azure/foundry/control-plane/how-to-manage-agents ).

For a wider view, Agent 365 has its own registry, and it covers both Microsoft and non-Microsoft agents ( learn.microsoft.com/entra/agent-id/agent-registry-convergence ). So the single view the session describes exists, but it takes some setup to get there.

Building and testing in the console

The Agents Management Console is where you build and debug agents. You create an agent, give it a unique ID, and connect an Azure OpenAI deployment to a knowledge base through integrated vector stores. The session used GPT-4o Mini as its example.

From there you can set up prompt flows, fine-tuning pipelines, content understanding models, and automated red teaming. The tracing and monitoring tabs show the agent's reasoning steps, its tool calls, and its latency.

One useful check is that you can confirm the guardrails catch unsafe prompts before a response reaches a real user. It makes sense to run that check before launch.

Choosing a model

No single model fits every job. Cost, latency, reasoning depth, throughput, and domain fit all change from one use case to the next.

The Foundry model leaderboards compare models on four things: quality, safety, estimated cost, and throughput. They also have trade-off charts, such as quality against cost, and a side-by-side view for up to three models. Two limits are worth knowing. The leaderboards are in preview, and they cover text language models and embedding models, scored on public datasets ( learn.microsoft.com/azure/foundry/concepts/model-benchmarks ).

That makes them a good way to build a shortlist. Before you commit to a model, run your own test on your own data.

Zero Trust in four rules

Microsoft's Zero Trust approach comes down to four rules:

  1. Assume no implicit trust, even inside internal subnets. Where a user or device sits on the network tells you nothing about whether to trust it.
  2. Verify continuously. Check every request, not only the login.
  3. Use least privilege. Use just-in-time (JIT) and just-enough access (JEA), so a stolen credential does less damage.
  4. Assume breach. Design as if attackers are already inside, and limit how far they can move sideways.

Here is how the session says Microsoft puts those rules to work. Entra ID manages user and workload identities. Microsoft Intune and Defender for Endpoint report on device health. Those signals feed Microsoft Entra Conditional Access, which is the central policy engine.

Conditional Access then applies its decisions across:

  • Data classified by Microsoft Purview
  • SaaS and on-premises apps protected by Defender for Cloud Apps
  • Network segments secured through Entra Private Access and Entra Internet Access
  • Infrastructure across Azure, hybrid clouds, and serverless runtimes

Threat intelligence flows back in from Microsoft Defender XDR and Microsoft Sentinel. In fact, this return path matters. What the security tools detect changes the policy, and the changed policy shapes the next access decision.

SASE in four pieces

Secure Access Service Edge (SASE) combines software-defined networking with Zero Trust security as one cloud service. It replaces the older hub-and-spoke design, where remote traffic goes back through a central data center for inspection. That path adds delay and works poorly with cloud apps.

SASE has four parts. Each one answers a different question.

  • SD-WAN: answers "How does traffic get there quickly?" It routes across fiber, MPLS, and 5G by watching packet loss, jitter, and app priority. Admins set routing policy in one place.
  • Secure Web Gateway (SWG): answers "Is this web traffic safe?" It filters inbound and outbound traffic in real time, blocking malware and phishing and enforcing acceptable use.
  • Cloud Access Security Broker (CASB): answers "Which cloud apps are people using, and with what data?" It shows app usage, applies data loss prevention rules, flags unusual behavior, and exposes shadow IT.
  • Zero Trust Network Access (ZTNA): answers "Who can reach which app?" It grants access to one application at a time instead of a whole network.

Two details are worth knowing.

First, the session says over 90% of web traffic is encrypted, and that holds. Cloudflare Radar data for the third quarter of 2026 puts HTTPS at about 95% of all requests on Cloudflare's network, and about 99% of human traffic ( technologychecker.io/blog/https-adoption ). That counts requests, not websites. It means a good SWG has to decrypt, inspect, and re-encrypt TLS traffic without slowing users down. Modern SWGs run as cloud services, so an employee gets the same scanning at headquarters and in a coffee shop.

Second, the difference between a VPN and ZTNA. After a remote user signs in through a VPN, they usually get broad access to the whole corporate subnet. Malware on their device gets the same access. ZTNA gives access one app at a time, based on identity, device health, and context. If a credential is stolen, the attacker can't move to other systems, because they never see the network.

What I checked

I checked the session's claims about Foundry against Microsoft Learn on October 11, 2026. Here is how each one came out:

  • Naming history: confirmed, with one extra step in the middle (Azure AI Foundry).
  • Foundry components: all real except Redis semantic caching, which is something you build yourself.
  • Third-party agents: partly true, as described above.
  • The 90% encrypted-traffic figure: holds, and is on the low side.

I also removed one claim. The session ties Microsoft Sentinel to the Foundry Control Plane, and I could not find that in the Control Plane docs. They name Defender and Purview alerts.

Three limits remain. The HTTPS numbers come from a site that reports Cloudflare Radar data. The Radar page itself showed no numbers when I loaded it. I did not check the Zero Trust and SASE product details, such as the Entra and Defender names, against the docs. And I did not verify the session's claims about one-click model deployment and license tracking, so I left license tracking out.

Where to start

You don't need to adopt all of this at once. Pick one agent in your environment and ask two questions. Is it running well and safely? Is it allowed to act? If you can't answer both quickly, that gap is a good first project.

No comments yet

Continue reading