How Azure Virtual Network Integration Secures Hosted AI Agents

In this blog post How Azure Virtual Network Integration Secures Hosted AI Agents we will explain how private networking helps stop a useful AI tool from becoming an uncontrolled doorway into your business systems.

This matters because a hosted AI agent is not simply a chatbot. It can read documents, search databases, call internal applications, create support tickets and trigger business processes. If its network access is poorly designed, one compromised agent could provide a path to sensitive data or critical services.

What Azure Virtual Network integration actually does

A hosted agent runs your custom AI application code on managed Azure infrastructure. Microsoft handles much of the underlying computing, scaling and availability, while your team controls the agent’s instructions, tools and business logic.

For more detail on when this model makes sense, see our comparison of Azure Foundry prompt agents and hosted agents.

An Azure Virtual Network, usually shortened to VNet, is a private network inside Azure. VNet integration connects the agent’s managed computing environment to that network, allowing it to reach approved internal resources without sending traffic across the public internet.

Microsoft Foundry hosted agents can use a customer-provided VNet for outbound traffic. The agent runs on isolated managed compute, receives its own Microsoft Entra identity and can access private databases, storage services and internal application programming interfaces, or APIs, which allow different applications to communicate.

User or business application
 |
Private Foundry endpoint
 |
Hosted AI agent
 |
Delegated VNet subnet
 |
Private endpoints
 |
Approved databases, storage and internal APIs

Think of it as moving the agent from an open office lobby into a controlled work area. It can still do its job, but it can only use the doors, systems and information you deliberately make available.

Why the default network setup may not be enough

A public endpoint is not automatically insecure. Authentication and access controls still apply. The problem is that internet-accessible services create a larger area for your security team to monitor and defend.

In the default public networking model, the Foundry endpoint can be reached over the internet by someone with valid credentials and the endpoint address. Agent connections to business resources may also use public networking unless you configure stronger restrictions.

That may be acceptable for an early demonstration using test data. It is rarely the right long-term design for an agent processing customer records, financial information, employee documents or operational data.

Five business benefits of VNet integration

1. It reduces unnecessary internet exposure

Private endpoints give Azure services a private network address. Your agent can connect to storage, databases and other services without those resources accepting connections from the public internet.

The business outcome is a smaller attack surface. There are fewer public entry points to protect, fewer firewall exceptions to maintain and fewer opportunities for a stolen credential to be used from an unexpected location.

2. It controls where the agent can send information

Inbound traffic is what reaches your agent. Outbound traffic, also called egress, is what the agent sends to other systems. Both directions matter.

An agent may need to call a customer management platform or an approved external service. It should not have unrestricted access to every internet destination. Routing outbound connections through your controlled network allows security teams to inspect, restrict and record those connections.

This reduces the risk of sensitive information being sent to an unapproved service because of faulty code, a malicious instruction hidden in a document or an incorrectly configured tool.

3. It allows private access to business data

Many useful agents need access to Azure Storage, Azure Cosmos DB, Azure AI Search, Key Vault or internal applications. VNet integration enables those connections to remain private when the supporting resources are configured with private endpoints.

Microsoft’s private networking setup can provide no public egress, a customer-provided delegated subnet and private access to supporting Azure resources.

This is particularly important when the agent handles personal information covered by Australian privacy obligations or data subject to contractual residency and access requirements.

4. It supports identity-based access instead of stored passwords

Network isolation should work alongside identity controls. Each hosted agent receives a dedicated Microsoft Entra identity, which is a digital identity Azure services can recognise.

You can then give the agent permission to read one storage location or call one API without placing passwords or access keys inside its code. If the agent does not need to delete records, it should not receive deletion rights.

This least-privilege approach limits the damage caused by mistakes or compromise. It also makes access reviews easier because permissions are attached to a named agent identity rather than a shared secret.

5. It creates clearer evidence for audits

VNet flow records, firewall logs, agent activity logs and Microsoft Defender alerts can help show which systems the agent contacted and whether unusual traffic occurred.

Network isolation does not make an organisation compliant by itself. However, it supports the controlled access, monitoring and system hardening expected by security assessors and complements the Essential 8, the Australian Government’s baseline cybersecurity framework.

For agent records and evidence trails, our guide to building audit-ready AI agents with Azure Cosmos DB covers the data layer in more depth.

A practical deployment approach

Secure networking is easiest to implement before an agent reaches production. Retrofitting it later can involve changing application connections, private Domain Name System settings, firewall rules and deployment pipelines.

1. Map the agent’s connections. List every model, database, file store, API and external service the agent needs.
2. Separate development and production. Test agents should not share unrestricted access to live customer data.
3. Create a dedicated subnet. A subnet is a reserved section of your VNet. Plan enough network addresses for agent growth and supporting services.
4. Add private endpoints. Remove public access from storage, databases and other sensitive dependencies wherever practical.
5. Use the agent’s Entra identity. Grant only the permissions required for its approved tasks.
6. Restrict outbound destinations. Allow approved services rather than giving the agent open internet access.
7. Enable monitoring. Send network, identity and agent logs to a central monitoring platform and define alerts for unusual behaviour.
8. Test failure scenarios. Confirm what happens when a database, private endpoint or external service is unavailable.

Subnet capacity deserves particular attention. Hosted-agent compute and Foundry networking components consume private network addresses, so a subnet that works during a small trial may become a production bottleneck as usage grows.

A common 200-person company scenario

Consider a 200-person professional services company building an agent to summarise client documents and update its project management system. The proof of concept uses public endpoints because that is quick and convenient.

Before launch, the security review finds that the agent can reach more storage accounts than it needs and can connect to unrestricted internet destinations. A malicious instruction hidden in an uploaded document could potentially influence the agent to send information to an unapproved service.

The company places the hosted agent inside a controlled VNet design, adds private endpoints for document storage and gives the agent identity read-only access to one approved data location. Outbound access is limited to the model service and project management API.

The agent’s business value remains the same. The difference is that a mistake is less likely to become a reportable data incident, and the company can explain the controls clearly to clients, insurers and auditors.

What businesses often get wrong

• They secure the model but not the surrounding services. Storage, APIs and agent memory can expose just as much sensitive information.
• They assume a private endpoint controls outbound traffic. Private inbound access and restricted outbound access are separate design decisions.
• They reuse broad developer permissions. Production agents need their own identities and narrowly defined access.
• They forget monitoring. A private network reduces exposure, but it does not tell you when an agent behaves unexpectedly.
• They design only for today’s pilot. Network capacity, availability and cost should account for future agents and users.

These controls should form part of the wider architecture described in Designing Secure AI Agent Infrastructure on Azure and our security best practices for Azure AI services.

Private networking should support the business, not slow it down

The goal is not to build the most complicated network possible. It is to give the agent the access required to produce a measurable business result while removing connections it does not need.

CloudProInc brings more than 20 years of enterprise IT experience to this work. As a Microsoft Partner and Wiz Security Integrator, our Melbourne-based team takes a practical approach across Azure, Microsoft Defender, Wiz and AI platforms including OpenAI and Anthropic Claude.

If you are unsure whether your hosted agent is exposing more of your network or data than it should, we are happy to review the design and explain the gaps in plain English — no strings attached.