Introduction
AI agents are increasingly being connected to APIs, databases, internal services, file stores, and external applications. This makes them useful, but it also creates a security boundary that needs to be designed carefully.
An agent may need network access to complete a task, but unrestricted connectivity can create unnecessary risk. An agent that can reach every available endpoint may be able to access services that were never required for its job.
Network access should therefore be treated as part of the agent's security architecture, not as an afterthought.
Microsoft Foundry provides capabilities for building and operating AI applications and agents. When deploying agents that interact with external resources, developers need to understand how networking, identity, authorization, and application-level controls work together.
This article explains the main principles for controlling AI agent network access in Microsoft Foundry and how to design a more controlled production architecture.
Why Network Access Matters for AI Agents
A traditional application normally follows predefined code paths.
An AI agent introduces another decision-making component:
User
|
v
AI Agent
|
+----> API
|
+----> Database
|
+----> Search
|
+----> External Service
The model can decide which available tool or capability should be used based on the request and instructions.
That makes the list of available network destinations important.
For example, an expense-processing agent may need access to:
Expense API
Document Storage
Approval Service
It probably does not need direct access to:
Payroll Database
Production Administration API
Customer Identity Database
Internal Management Console
Giving the agent access to all of them increases the attack surface.
Network Access and Authorization Are Different
One of the most important concepts is that network reachability is not the same as authorization.
Consider:
Agent
|
v
Network
|
v
Internal API
|
v
Authorization
|
v
Business Operation
Network controls determine whether traffic can reach a destination.
Identity and authorization determine whether that destination should allow the requested operation.
Both layers are necessary.
An application should not assume that because an endpoint is unreachable from the public internet, an AI agent is automatically authorized to use it.
A Layered Security Model
A practical architecture uses several controls.
User
|
v
Agent Application
|
+--------+--------+
| |
v v
Model/Agent Policy Layer
|
v
Tool Authorization
|
v
Network Controls
|
+-------------+-------------+
| | |
v v v
API Storage External Service
Each layer has a different responsibility.
Layer | Primary responsibility |
|---|---|
Identity | Establish who is making the request |
Agent instructions | Define intended behavior |
Tool authorization | Control which actions are allowed |
Network controls | Restrict connectivity |
API authorization | Enforce service-level permissions |
Data permissions | Restrict accessible information |
Monitoring | Detect unexpected behavior |
The model should not be the only security mechanism.
Define the Agent's Network Requirements
Before configuring networking, document exactly what the agent needs.
For example:
Agent: Invoice Processing Agent
Required:
- Invoice API
- Document storage
- Vendor validation API
Not required:
- Employee database
- Production database
- Administration APIs
- Internal source-control systems
This creates a simple allowlist.
An allowlist approach is generally easier to reason about than giving an agent broad access and attempting to block individual destinations later.
Use Private Connectivity Where Required
Enterprise applications often need access to resources that should not be exposed directly to the public internet.
Depending on the architecture and supported Microsoft Foundry capabilities, private networking features can be used to create controlled connectivity between the AI application and Azure resources.
A simplified architecture can look like:
Azure Environment
|
+-- Microsoft Foundry
| |
| v
| Agent
| |
| v
| Controlled Network
| |
| +---- Private API
| |
| +---- Storage
| |
| +---- Database
|
+-- Monitoring
The exact networking configuration depends on the services involved, their network capabilities, and the deployment architecture.
The important design principle is to avoid exposing sensitive resources simply because an agent needs to communicate with them.
Control Egress Traffic
Ingress controls protect resources from unwanted incoming connections.
Egress controls address the opposite direction:
Agent
|
+----> Approved API
|
+----> Approved Storage
|
+----> Blocked Destination
For agent-based systems, egress deserves particular attention because an agent can potentially generate requests based on model output.
A controlled egress design can restrict outbound traffic to approved destinations.
For example:
Allowed:
api.internal.example
storage.internal.example
approved.vendor.example
Denied:
unknown destinations
unapproved external services
administrative endpoints
The implementation should use the network controls available in the surrounding Azure architecture rather than relying on prompt instructions alone.
Do Not Trust the Model to Enforce Network Policy
A prompt can say:
Only call the approved payment API.
Never access other services.
That is useful guidance, but it should not be treated as a network security control.
A model can misunderstand instructions, encounter prompt injection, or select an unexpected tool.
A stronger architecture is:
Model Decision
|
v
Application Policy
|
+---- Is tool allowed?
|
+---- Is destination allowed?
|
+---- Is user authorized?
|
v
Network Request
The application or platform should enforce the policy.
Control Tools as Well as Network Destinations
Network restrictions alone do not solve the complete problem.
Suppose an agent can reach an order API:
https://orders.internal.example
The API may expose:
GET /orders/{id}
POST /orders/{id}/cancel
POST /orders/{id}/refund
DELETE /orders/{id}
The agent may only need read access.
Therefore, access should be limited at the tool and API level as well:
Agent
|
+-- get_order Allowed
|
+-- search_order Allowed
|
+-- cancel_order Approval required
|
+-- refund_order Denied
This is a defense-in-depth approach.
Use Managed Identities Where Appropriate
When an agent application needs to access Azure resources, avoid embedding long-lived credentials in prompts, configuration files, or source code.
A managed identity can provide an identity for an Azure-hosted workload, allowing Azure resources to authorize requests through Microsoft Entra ID.
The general flow is:
Agent Application
|
v
Managed Identity
|
v
Microsoft Entra ID
|
v
Azure Resource
Permissions should follow least privilege.
If the application only needs to read from a storage resource, it should not receive permissions that allow unrelated administrative operations.
Separate Read and Write Capabilities
AI agents often need to read information more frequently than they need to modify it.
Treat these capabilities differently.
For example:
Capability | Access |
|---|---|
Search invoices | Read |
Retrieve invoice | Read |
Create invoice | Write |
Approve invoice | Sensitive write |
Delete invoice | Highly sensitive |
Sensitive operations can require additional controls such as explicit user confirmation, application approval, or a separate authorization workflow.
This is particularly important for autonomous agents.
Protect Against SSRF-Style Behavior
Server-side request forgery (SSRF) is a relevant consideration for applications that allow server-side components to make network requests based on input.
AI agents introduce an additional source of dynamic input because the model can generate tool arguments or URLs.
For example, avoid designs where a model can freely provide an arbitrary URL to a generic HTTP tool:
{
"url": "https://any-destination.example"
}
A safer design is to expose narrowly defined tools:
get_customer_profile(customerId)
get_invoice(invoiceId)
search_orders(query)
The application determines the actual endpoint.
This reduces the model's ability to turn a general-purpose HTTP capability into an unrestricted network client.
Monitor Network Activity
Security controls should be observable.
Monitor:
Destination hostnames
Connection attempts
Denied requests
Successful requests
Authentication failures
Unusual request volume
Tool invocation patterns
Requests outside normal business workflows
A useful operational pattern is:
Agent Request
|
v
Policy Check
|
+---- Denied --> Log
|
+---- Allowed
|
v
Network Request
|
v
API Response
|
v
Log
Logs should contain enough information to investigate incidents while respecting privacy and data-handling requirements.
Troubleshooting Network Access
When an agent cannot reach a required service, avoid immediately opening network access broadly.
Use a structured process.
Step 1: Confirm the Destination
Verify the hostname, port, protocol, and required endpoint.
Step 2: Check Identity
Determine which identity the application is using.
Step 3: Check Authorization
Confirm that the identity has the required permission on the target resource.
Step 4: Check Network Configuration
Review private endpoints, firewall rules, routing, DNS, and outbound restrictions as applicable to the architecture.
Step 5: Check Application Policy
A network request can fail because the application's own tool authorization layer rejected it.
Step 6: Review Logs
Look for the first point where the request was rejected.
This is much safer than responding to an access problem by allowing unrestricted outbound connectivity.
Common Mistakes
Giving the Agent Internet Access by Default
Broad connectivity increases the number of destinations that need to be trusted.
Treating Prompt Instructions as Security Controls
Prompts guide model behavior. They do not replace network firewalls, identity controls, or authorization policies.
Giving One Identity Too Many Permissions
An agent should not inherit broad permissions simply because several tools happen to run under the same application identity.
Using Generic HTTP Tools
A generic URL-fetching capability can create unnecessary security exposure.
Prefer purpose-built tools with fixed destinations.
Ignoring Write Operations
Read-only access and destructive operations should not automatically receive the same authorization.
Skipping Monitoring
Without logs, unexpected network behavior can be difficult to investigate.
Best Practices
Define an explicit network access inventory for every agent.
Prefer allowlisted destinations over unrestricted outbound access.
Separate network reachability from authorization.
Use managed identities where supported and appropriate.
Apply least-privilege permissions.
Keep sensitive write operations behind additional authorization.
Prefer narrowly scoped tools instead of generic HTTP access.
Use private connectivity for sensitive resources when required by the architecture.
Monitor both successful and denied network requests.
Test prompt-injection and unexpected-tool scenarios.
Review network permissions whenever an agent gains a new tool.
Treat networking as part of the agent's threat model.
Advantages and Disadvantages
Advantages | Disadvantages |
|---|---|
Reduces unnecessary network exposure | Requires additional architecture and configuration |
Supports least-privilege agent design | Troubleshooting can involve multiple layers |
Limits destinations available to agents | Private networking can increase operational complexity |
Works together with identity and API controls | Network policies need ongoing maintenance |
Provides stronger defense against unexpected tool behavior | Overly restrictive rules can break legitimate workflows |
Production Checklist
Before deploying an agent that requires network access, verify:
[ ] Required destinations are documented
[ ] Unnecessary destinations are blocked
[ ] Agent identity is defined
[ ] Permissions follow least privilege
[ ] Tool-level authorization is implemented
[ ] Sensitive write operations have additional controls
[ ] Private connectivity is used where appropriate
[ ] Generic unrestricted HTTP access is avoided
[ ] Network activity is logged
[ ] Denied requests are observable
[ ] Prompt-injection scenarios have been tested
[ ] Network configuration is included in deployment documentation
Summary
Controlling AI agent network access requires more than configuring a firewall or adding restrictions to a system prompt.
A production agent should operate inside several security boundaries: identity, tool authorization, network controls, API permissions, and monitoring.
Start by identifying exactly which services the agent needs. Restrict connectivity to those destinations, use least-privilege identities, and avoid giving the model unrestricted network tools.
Most importantly, do not rely on the model to enforce security policy. The model can decide what it wants to do, but the surrounding application and infrastructure should determine what it is actually allowed to do.
This layered approach makes AI agents easier to reason about and reduces the impact of unexpected model behavior, prompt injection, or incorrectly selected tools.
Join the conversation! Your thoughts help the community grow.