In this blog post How to Publish Private AI Agents Without Public Internet Exposure we will explain how to make an internal AI agent available to employees and business systems without placing the agent itself on a public internet endpoint.
This is a common sticking point for organisations moving AI agents into production. The agent works securely inside a private Azure network, but employees need to reach it through Teams, Microsoft 365 or an internal application. The quick fix is often to enable public access, which can undo much of the security work already completed.
The better approach is private publishing. This gives approved users and applications a stable way to call the agent while its data, tools and core endpoint remain inside a controlled network boundary.
Publishing does not have to mean making an agent public
Publishing simply means making an agent available through a supported business channel. It does not mean that anyone on the internet should be able to reach its endpoint.
For example, an employee might open an agent in Microsoft Teams. Behind the scenes, Teams authenticates the employee and sends the request through an approved service path. The agent can remain connected privately to internal documents, databases and business applications.
This separation matters because an agent is more than a chatbot. It may be able to read customer records, create service tickets, query financial systems or trigger workflows. Our guide to designing secure AI agent infrastructure on Azure explains why these capabilities require application-grade security.
The technology behind private AI agent publishing
The main technology is Azure Private Link, together with private endpoints and Azure Virtual Networks. In plain English, these services give an Azure resource a private network address so traffic can reach it without travelling through a publicly accessible endpoint.
Private endpoints keep inbound access private
A private endpoint places the Microsoft Foundry service on a private IP address inside your Azure network. Public network access can then be disabled, preventing ordinary internet connections from reaching the Foundry project or its agents.
Only systems with a valid route into that network can connect. This may include an Azure-hosted application, an employee connected through a company VPN, an office connected using ExpressRoute, or another approved Azure network.
Virtual network integration controls outbound traffic
Inbound protection is only half the job. The agent also needs controls over where it can send information.
Azure Virtual Network integration connects the agent runtime to a controlled network. This allows it to reach approved databases, storage accounts and internal APIs while blocking unnecessary destinations. We cover that layer in more detail in how Azure Virtual Network integration secures hosted AI agents.
Private DNS directs traffic to the right place
Private DNS makes the agent’s normal service name resolve to its private IP address. Without it, an application may try to use the public route even when a private endpoint exists.
DNS is one of the most frequently missed parts of private publishing. When it is wrong, teams often assume private networking has failed and temporarily re-enable public access.
Microsoft Entra ID decides who is allowed in
A private network reduces exposure, but it does not replace authentication. Microsoft Entra ID, Microsoft’s identity and access service, should verify every user, application and agent.
Each agent should have its own identity and only the permissions required for its job. Avoid shared administrator accounts, permanent access keys and secrets stored in code. This reduces the damage possible if an agent, application or credential is compromised.
Four practical ways to publish a private agent
1. Publish it through an internal business application
The simplest model is often an internal web application hosted inside the same Azure network. Employees sign in with their Microsoft 365 identity, and the application calls the agent through its private endpoint.
This works well for finance, operations and service desk agents. It keeps the user experience familiar while avoiding direct user access to the Foundry project.
2. Use a private API gateway for business systems
If several applications need the agent, Azure API Management can provide a consistent internal address. API Management acts as a controlled reception desk for software requests, checking identity, applying usage limits and recording activity before passing requests to the agent.
It can be deployed for private access only. This gives the business one governed integration point rather than allowing every application to connect differently.
3. Publish to Microsoft Teams and Microsoft 365
A private Microsoft Foundry agent can be made available through Microsoft Teams and Microsoft 365 Copilot using the supported publishing process, including Azure Bot Service and the appropriate activity protocol and authorisation settings.
For private projects, additional network configuration is required because Microsoft 365 channel services do not run inside your company network. The answer is not to enable unrestricted public access. It is to authorise the required Microsoft service path while keeping public network access disabled.
Organisations should also review what information Teams and Microsoft 365 process, where it is stored and whether that matches internal privacy and data residency requirements.
4. Place a controlled gateway in front of partner access
External partners may not have access to your private network. In that case, expose a tightly controlled gateway rather than the agent itself.
The gateway should require strong authentication, inspect requests, apply rate limits and block unexpected traffic. Azure Application Gateway with a web application firewall can provide this protective layer, while the agent remains on a private backend connection.
What the reference design looks like
A secure design normally follows this request path:
- The employee or application signs in using Microsoft Entra ID.
- An internal application, Teams channel or approved gateway receives the request.
- The publishing layer checks identity, permissions and usage limits.
- The request travels to the agent through an approved private or service-specific path.
- The agent uses its own identity to access only the data and tools it needs.
- Microsoft Defender, Azure Monitor or a security platform such as Wiz records and monitors the activity.
The intended security position can be summarised as follows:
Agent public network access: Disabled
Inbound access: Private endpoint or approved service path
User authentication: Microsoft Entra ID
Agent authentication: Dedicated managed identity
Outbound destinations: Approved services only
Secrets in application code: None
Logging and alerting: Enabled
This is a policy summary rather than a deployment template. The exact Azure configuration depends on how users access the agent and which systems it needs to reach.
A practical 200-person business scenario
Consider a 200-person professional services company building an agent that searches project files, summarises client history and creates tasks in its service management platform.
Making the agent publicly reachable would increase the number of systems the security team must monitor and test. Giving employees direct Foundry access would create unnecessary administration and increase the chance of someone changing the wrong configuration.
Instead, the company publishes the agent in Teams. Employees use their existing Microsoft 365 accounts, the Foundry project remains private, and the agent receives read-only access to approved project libraries.
The outcome is a simpler user experience, fewer support requests and a smaller attack surface. The company also avoids buying and maintaining a separate AI portal when Teams already provides the required interface.
Common mistakes that create unnecessary risk
- Treating private networking as complete security. Users and agents still require tightly controlled identities and permissions.
- Allowing unrestricted outbound access. A private agent should not be able to send data to any internet destination it chooses.
- Re-enabling public access during troubleshooting. Check private DNS, routes and firewall rules before weakening the design.
- Giving every agent broad permissions. An HR agent should not automatically have access to finance or customer systems.
- Overengineering the solution. An internal application may only need a private endpoint and Entra ID, not several expensive gateway products.
These controls also support the intent of the Essential Eight, the Australian government’s cybersecurity framework that many organisations use as a security baseline. In particular, strong authentication and restricted privileges help align agent access with multi-factor authentication and administrative access controls. Private networking alone, however, does not make an organisation Essential Eight compliant.
Start with the access requirement
Before choosing Azure services, identify who needs the agent, where they will use it and what the agent must access. Then select the least complex publishing path that meets those requirements.
Our earlier article on designing private network access for Microsoft Foundry agents covers the underlying network boundary. If agents also need to advertise their capabilities to other systems, review publishing Agent Cards safely without disclosing sensitive internal details.
CloudProInc approaches these designs as a Microsoft Partner and Wiz Security Integrator with more than 20 years of enterprise IT experience. The goal is not to add as many Azure services as possible. It is to give the business a secure, supportable route to its AI agents without creating unnecessary cost or operational complexity.
If you are not sure whether your private AI agent can be published safely, or whether your current design is more complex than it needs to be, CloudProInc is happy to review it with you — no strings attached.
Discover more from CPI Consulting
Subscribe to get the latest posts sent to your email.