This is part of my series on Microsoft Foundry:

1. Microsoft Foundry’s Evolution
2. Microsoft Foundry BYO AI Gateway (BYO Model) – Part 1
3. Microsoft Foundry BYO AI Gateway (BYO Model) – Part 2
4. Microsoft Foundry BYO AI Gateway (BYO Model) – Part 3
5. Microsoft Foundry Publishing Agent to Microsoft Teams – Part 1 – Overview
6. Microsoft Foundry Publishing Agent to Microsoft Teams – Part 2- The GUI Experience

Hello again fellow geeks. While I typically like to stick to one post every few weeks for sanity sake, I want to get this series down and recorded before I get distracted by something else and forget what is fresh in my mind. You know the feeling, right?

This post will continue my series on publishing agents built in the Microsoft Foundry Agent Service to Microsoft Teams. In my last post gave a brief over of the Foundry Agent Service, why you would publish an agent to Teams, and the role of the AI Bot Service in the process (at least as that role stands today). For this post my focus will be walking through the GUI-based experience for publishing an agent, where it works, where it doesn’t work, and the high level workflow of what happens when you hit the publish button.

Where the GUI process works

As it is today? Pretty much no where in my opinion. Sure muck around with it your lab, but any real enterprise environment it ain’t gonna work. Why? Well because of this big blue blurb in the documentation.

Let me dig in a bit into exactly what this blurb means. For any Azure-based PaaS service there is inbound traffic. Inbound traffic is when some endpoint initiates a connection to the Azure PaaS instance. For example, an inbound flow to Foundry might be an endpoint making a connection to a model endpoint to make an inference.

By default, every Microsoft PaaS service has a hostname in a public DNS zone that will resolve to a public IP (exempting some compute-based services where you can disable this) and every PaaS service allows inbound traffic to that endpoint by default. Whether or not traffic is accepted over the public endpoint is typically controlled by a property of the resource named publicNetworkAccess. In the case of Microsoft Foundry this setting is set at the Foundry account level. Below is an example of a Foundry account that has inbound public network access disabled.

{
    "id": "/subscriptions/97515654-3331-440d-XXXXXXXXXXXX/resourceGroups/rgmsfcusg5b111/providers/Microsoft.CognitiveServices/accounts/msfcusg5b111",
    "name": "msfcusg5b111",
    "type": "Microsoft.CognitiveServices/accounts",
    "location": "centralus",
    "sku": {
        "name": "S0"
    },
    "kind": "AIServices",
    "tags": {
      ...
    },
    "properties": {
        ...
        "publicNetworkAccess": "Disabled",
}

When the publicNetworkAccess property is set to disabled for Microsoft Foundry, all inbound traffic to the public endpoint will be denied by the service firewall. This means no IP exceptions and no exceptions for service endpoint traffic. It can still support inbound traffic to the public endpoint for its specific set of trusted Azure services. I go into the gory details of how the PaaS service firewall works, what the trusted service exception is, and the other types of exceptions you can use for the service firewall depending on the PaaS service and all that other fun nerd stuff in my series on Network Security Perimeters if you want to dig in. It’s worth a read if you’re a heavy service firewall user today, because Network Security Perimeters on are track to replace that functionality (and they do a WHOLE lot more).

For the purposes of this post, know the service firewall exists and it is the thing denying inbound traffic when we set publicNetworkAccess to disabled. If you attempt to publish a Foundry agent that has publicNetworkAccess (often referred to as PNA) set to disabled, you’ll receive this error:

All of that was a long and overly wordy way of saying the GUI process as it is today will not work for any customer that disabled inbound public network access, which is pretty much every large enterprise customer. Where it may work is for sandbox-like environments where security controls are minimal or if your specific org isn’t subject to strict security controls and inbound PNA isn’t a problem.

How does the GUI process works

You may be saying, “Why should I care if I can’t use it?” Valid question, but for quick proof-of-concepts or sandbox like environments it has a role. It’s also helpful to get a feeling for the overall publishing workflow. While it may be more compact and simple via the GUI process, the programmatic steps don’t differ all too much. There simply are more and you have more configuration options.

Before you run these steps you’ll need to ensure you have the specific set of permissions over Bot Services or be granted the Azure Bot Services Contributor role, Contributor role, or Owner role at the resource group or subscription. Additionally, you’ll require the Foundry User role on the Foundry project.

Let’s assume we have a new Foundry account, PNA is enabled, we got the permissions mentioned above, we’ve created a project, and we’ve created a new prompt agent. In the top right hand corner we have pretty white button that says Publish. The option we’re interested in is the Teams & Microsoft 365 Copilot option as seen below highlighted in red.

If you’ve disabled inbound PNA on the Foundry account, you’d see the error I posted above when you click this.

In the next Publish to Teams and Microsoft 365 window you’ll be prompted to enter some information. Many of these inputs will be used to populate properties in the Agent 365 Agent Registry for the agent and will be used for the manifest file that is created for sideloading into Teams or pushed to the organization’s Teams App Store.

Notice that the Azure bot services field is populated automatically. This is because unbeknownst to you, clicking the Publish button created a Bot Services resource in the same resource group as the Foundry resource in the background. This is where the requirement for permissions over Bot Services comes into play. This behavior the requirement for a Bot Service resource may be going away (hooray) at some point in the near future.

You begin to see why this process isn’t very usable for an enterprise. This probably just triggered a crapload of Azure Policies you’ll now have to deal with around naming conventions, missing tags, PNA enabled for the Bot Service, and likely others.

Next, you’ll click on the Next: Publish options button. This will advance you to the Publish options screen. In the Direct Publish section you can choose to install this Teams app for yourself (essentially sideloads it from my understanding) or you can install it for the entire organization. The latter will trigger a request process in the Microsoft 365 Admin Portal in the Agent 365 Agent Registry window as we’ll see a bit later.

The Download & customize section allows you to download a ZIP file with the generated manifest in it if you need to further customize what the workflow has created.

I complete the workflow by clicking Publish.

Before I jump to the next section, I decided to be nosey and see if I could determine the endpoints being called to process the various API operations. It turns out that there are specific API endpoints behind the Foundry Portal that trigger the backend orchestration of the various API calls we’ll perform when we do it programmatically in the next post. Some of the endpoints of note are:

1. Press Publish to Teams and Microsoft 365 button
   • https://ai.azure.com/nextgen/api/query?listBotServicesResolver -> As best I can tell, this is querying to see if a Bot Service already exist.
   • https://ai.azure.com/nextgen/api/query?createBotService -> This makes the call that triggers the creation of the Bot Service resource in Azure.
2. Press Next: Publish Options
   • https://ai.azure.com/nextgen/api/query?prepareAgentForMicrosoft365V3Reolver -> Generates the manifest file that you can download?
3. Press Publish
   • https://ai.azure.com/nextgen/api/publishAgentToMicrosoft365V3Resolver
     Triggers the request workflow in M365 Admin Portal prepping the agent for publishing to Teams
   • https://ai.azure.com/nextgen/api/getPublishedAppDetails

If I pop over to the Microsoft 365 Admin Portal I can see the agent is pending approval in the Agent 365 Agent Registry where I can publish it to the Teams store to make it available to the wider organization I can outright reject it.

Before approving it, I can explore the information populated for the agent within the agent registry. I can see that the information I populated within the Foundry GUI populated the information in the registry. I also see that it has been assigned an Entra ID Agent Identity created from the Entra ID Agent Identity Blueprint created for the agent. I can also review permissions the agent requires (this will be primarily OAuth permissions via Entra as far as I can tell), any tools it has (haven’t messed with the Agent 365 Tools Registry yet), and information about the security of the agent consolidated from Purview.

When I hit the Publish to store button I trigger the final process. Here I can choose which users or groups can install the agent in Microsoft Teams and which have the agent pre-installed. I can apply an Agent 365 Policy Template (requires Agent 365 license) which can enforce specific conditional access policies, give it Entra ID access package, and assign custom security attributes (custom security attributes are an underused feature so I’ll dig more into this in future). Lastly, if the agent is requesting any permissions I’m able to accept them or deny the push to the store.

After I run through the workflow and publish it, I get the image below.

It can take a fair amount of time for the agent to appear for your users in the Teams store for your users to install. Sometimes it’s 15 minutes and sometimes it seems like forever. Typical joys of Teams caching and Microsoft’s seemingly random timers. Eventually the agent will appear as a Teams app your user can add.

Once the user adds the agent they can begin chatting with it. The first chat they send they’ll need be prompted to sign into Foundry. This sign in is required to validate the user has appropriate permissions to call the agent.

If the user doesn’t have the Foundry Agent Consumer role or equivalent permissions on the Foundry project the agent is in the user will receive an authorization error like the below.

Once user is granted the role on the Foundry project, the user can now converse with the agent!

At this point you’ve got an agent created in Foundry, which has an entry in the Agent 365 Agent Registry, and has been published as a Teams to the organization’s Teams store for authorized users to consume. Seems so simple right?

The reality

Now all of that went so perfect because the product group wrote some great orchestration that got executed automagically via calls to specific endpoints in the Foundry Portal. This only worked so perfectly because inbound PNA was enabled. While inbound is a big piece, there were also outbound network flows from the agent to a variety of endpoints I’ll walk through in my next post. In this setup we didn’t lock down outbound traffic so our traffic that is sent back to Teams (which is a separate initiated flow where the agent runtime initiates it) wasn’t blocked or filtered in any way. Effectively, we had something similar to the picture below. Public network access for inbound and outbound traffic is grand ain’t it?

If we look at the end to end publishing flow, it looks something like this flow diagram.

The harsh reality we face with this GUI experience is there are way too many show stoppers to ever use it in a real enterprise environment with even basic security controls. That will lead us to the more complex path of programmatic publishing which I’ll explore in the next post.

Summing it up

What I want you to take away today are GUIs are pretty, but GUIs rarely work in a real enterprise environment because GUIs tend to rely on simple environments with “less” restrictive security controls. There is a lot of complexity to this workflow today and unrestricted network access can be very effective at hiding those complexities and making a really clean GUI-based publishing experience.

There are other points worth paying attention to which will be relevant in the programmatic experience and are just good to let sink into your brain in general:

1. Today, for prompt agents and hosted agents, a Bot Service is required. This may change in the very near future.
2. Users calling the agents must have appropriate permissions to call the agent, even through Teams. Using the built-in Azure RBAC role of Foundry Agent Consumer can be an easy path to accomplish that.
3. Get familiar with Agent 365. Whether you like it or not, you will be interacting with it if you’re building agents in Foundry or doing anything with any agent in the Microsoft clouds.
4. When you see demos at Ignite or any other conference, it’s usually done in an environment where public network access for inbound and outbound traffic is completely unrestricted and the user has Owner or Admin-level privileges over the service they are interacting with. It will also look easy in those demos. Don’t expect that ease when you go and deploy it to your complex regulated environment.

Well, I’m burned out. Time to let the brain veg out with some classic Mr. Bean.