Governance & Security
Your Network Team Wants an IP List. Here's What to Give Them Instead
Why Copilot Studio has no static IP list, which controls actually govern traffic in and out of your agents and flows, and how I explain the options to security and network architects.
It usually arrives as a short email: “Can you send us the IP addresses for Copilot Studio so we can allowlist them?” It’s a reasonable request. But there’s no honest answer that fits in one list, and if you send one anyway, something will break later.
This is a common point of confusion, and it’s not the network team’s fault. The real question isn’t “which IPs?” It’s “which direction is the traffic going, and who needs to control it?” Once you answer that, there’s a better tool for almost every case. Here’s how I approach it.
A quick caveat
Statuses below are current as of October 2026. Several of these features are in preview, and network behaviour changes as services evolve. Before you commit to a design, check the current Microsoft Learn article for each feature.
In this post
- Why there’s no static IP list
- Service tags: the closest thing to a list
- Name the direction first
- Inbound: IP firewall and cookie binding
- Tenant isolation
- Private outbound: VNet support
- On-premises data gateway
- Endpoint filtering and advanced connector policies
- Start with the operating model
- What to tell your network team
- Checklist
01 Why there’s no static IP list
Power Platform is multi-tenant. When an agent calls a connector or a flow makes an HTTP request, the traffic leaves from shared Azure infrastructure whose addresses change over time.
Microsoft’s own guidance is explicit here. Don’t allowlist the IP addresses an environment happens to resolve to today, because they can change. Allow the ranges published for the relevant Azure service tags instead, and refresh them regularly from the service tag files.
So the accurate answer has two parts: there is no fixed, per-customer address, and if you must filter by public IP, you filter by service tag and accept that those ranges are shared.
An IP allowlist built on shared cloud ranges tells you the traffic came from Power Platform. It doesn’t tell you it came from your tenant.
02 Service tags: the closest thing to a list
Service tags are named groups of IP prefixes that Microsoft publishes and updates. Most have regional variants (for example AzureConnectors.CentralUS), which is what I recommend using. They’re tighter than the global tag and match the region your environment lives in.
| Service tag | What Microsoft Learn says it covers | When I’d use it |
|---|---|---|
| AzureConnectors (+ regional) | Prefixes used by managed connectors to make outbound calls to their target services. Custom connectors use the same outbound addresses. | Your API or database sits behind a firewall and an agent or flow reaches it through a connector |
| PowerPlatformInfra and PowerPlatformPlex | The Copilot Studio docs point Azure services that receive calls from Copilot Studio (for example Azure Bot Service skills) to these two tags | Azure-hosted endpoints that Copilot Studio calls directly |
| PowerPlatformPlex | Listed on the Power Platform requirements page as needed for Dataverse sandbox plug-ins calling external web services | Plug-in code calling your APIs |
| AzureCloud | Listed as needed for all Power Platform and Dynamics 365 services. It’s very broad. | Client-side proxies and egress rules, rarely as an inbound allowlist |
Get the ranges from the downloadable JSON file or, as Microsoft prefers, the Service Tag Discovery API. If your firewall can’t consume tags natively, schedule a job that refreshes the rule set. A manual copy-paste will go stale.
I’d temper expectations
Service tags are shared. Allowing AzureConnectors.EastUS lets in connector traffic from every tenant in that region, not just yours. Treat it as a coarse network filter, and put real access control in authentication on the endpoint itself.
03 Name the direction first
Most confusion comes from mixing up different questions, each with its own controls.
Inbound
Who can reach your environment?
Users, tools, and stolen tokens trying to get into Dataverse, Copilot Studio, or an agent. Controls: IP firewall, IP cookie binding, Conditional Access, agent authentication.
Outbound
What can your agents and flows reach?
Connectors, HTTP calls, MCP servers, and plug-ins calling your systems or the internet. Controls: data policies, endpoint filtering, advanced connector policies, VNet support, the gateway.
Cross-tenant
Which other tenants can data move to?
Connections signed in to a different Entra tenant. Control: tenant isolation.
04 Inbound: IP firewall and cookie binding
IP firewall
Available for DataversePreview for Copilot StudioManaged Environments required
The IP firewall checks the source address of every request to Dataverse in real time and blocks anything outside your allowed ranges. It covers interactive and non-interactive access, so a stolen token used from an unknown network is refused. Copilot Studio extends it to the maker portal and agent conversations, in preview.
What to know before you turn it on
- It only applies to Managed Environments with Dataverse.
- Start in audit-only mode. It logs what would be blocked without blocking it.
- For agents, it’s enforced on web chat and conversational APIs. Agents published to Teams, Microsoft 365 Copilot, and some other channels don’t enforce it yet.
- You can set it once at the environment group level so new environments inherit it.
IP address-based cookie binding
AvailableManaged Environments only · off by default
Cookie binding ties a Dataverse session cookie to the IP address it was issued to. If someone copies the cookie and replays it from another machine, Dataverse blocks the request. One limit: it doesn’t work if your traffic goes through a reverse proxy with a dynamic IP address.
05 Tenant isolation
Tenant isolation controls whether connections can be established to and from other Entra tenants. With it on, a maker in your tenant can’t create a connection that signs in to an outside tenant (outbound), and users in another tenant can’t connect to your data sources (inbound), even with valid credentials. You add exceptions per tenant and per direction.
It’s narrower than people assume. It only applies to connectors that use Entra ID authentication, such as SharePoint or Office 365 Outlook. It’s also separate from Entra-wide tenant restrictions. The Azure DevOps connector has a known gap. Before turning it on, run the cross-tenant isolation report to see which existing connections would break.
06 Private outbound: VNet support
This is my most common answer when the requirement is “our endpoint must not be on the internet.” With Azure Virtual Network support, you delegate a subnet in your own Azure VNet to Power Platform. Supported workloads then make outbound calls from that subnet, under your network policies, so your endpoint can stay private and needs no service tags.
| Area | Supported over VNet (per Microsoft Learn) |
|---|---|
| Dataverse | Plug-ins |
| Connectors | SQL Server, Azure SQL Data Warehouse, Azure Queues, custom connectors, Azure Key Vault, Azure File Storage, Azure Blob Storage, HTTP with Microsoft Entra ID (preauthorized), Snowflake, Databricks, AI Search |
| Copilot Studio scenarios | HTTP Request node calls to private Azure resources (Key Vault is the documented example), telemetry to a private Application Insights instance, and agents using VNet-supported connectors |
The detail network teams care about
Internet-bound calls from a delegated subnet are allowed by default. Microsoft recommends attaching an Azure NAT gateway to the subnet so you control that egress. That’s the useful part for an allowlist: a NAT gateway gives you a public IP that you own. A partner or SaaS firewall can allow that one address, and it won’t change unless you change it.
What to plan for
- The environment must be a Managed Environment, and you need an Azure subscription linked to the tenant.
- Delegate subnets in both paired Azure regions, so failover works.
- Size the subnet properly. Microsoft’s guidance is about 25 to 30 IPs per production environment and 6 to 10 per non-production one, plus five reserved per subnet.
- Turning delegation on or off can cause up to 30 minutes of instability. Schedule it.
07 On-premises data gateway
The gateway is still the right tool when the system lives in your data center and you don’t have, or don’t want, a VNet path to it. You install it on a Windows server that can reach the target. The gateway opens outbound connections to the Microsoft cloud, so you don’t need to open inbound firewall ports, and calls to your system come from the gateway machine’s own address.
Connectors that support the gateway, including custom connectors, can be used from Copilot Studio agents and flows.
What I recommend
Cluster, patch, and monitor the gateway like production infrastructure. Note that SQL Server connections through a gateway aren’t supported in an environment linked to a VNet.
From the field
A financial services firm wanted to connect a Copilot Studio agent to an MCP server sitting in front of their data warehouse. The warehouse’s network policy only accepted allowlisted IPs, so they asked for the Copilot Studio range. I first asked who hosted the MCP server and which endpoint needed the restriction, then explained the regional service tags. My real recommendation was architectural: put the environment on VNet support with a NAT gateway, so the warehouse only has to trust one address they own. The on-premises data gateway was the lighter fallback.
08 Endpoint filtering and advanced connector policies
Network controls decide where packets go. Data policies decide what makers can configure. You want both.
Connector endpoint filtering
PreviewInside a classic data policy
Endpoint filtering lets you allow or deny specific destinations for a small set of connectors: HTTP, HTTP with Microsoft Entra ID, HTTP Webhook, SQL Server, Azure Blob Storage, SMTP, Browser Automation, and UI Automation. In Copilot Studio, a denied endpoint in a Send HTTP request node shows up as a policy violation.
The limit that matters
It only evaluates static endpoints entered at design time. Endpoints built from environment variables, custom inputs, or values resolved at runtime aren’t checked. For SQL Server and Blob Storage, it isn’t enforced when the connection uses Entra ID authentication. Use it as a guardrail, not as your only egress control.
Advanced connector policies (ACP)
Generally available (June 2026)Environment groups or single environments
ACP replaces the Business, Non-Business, and Blocked model with a strict allowlist. Everything is blocked unless you allow it, including new connectors. You can allow specific actions and block entire MCP servers. Per-tool control inside an MCP server isn’t available yet.
What to know
- It covers certified connectors and MCP connectors. Custom connectors and HTTP aren’t supported yet, so keep classic data policies and endpoint filtering for those.
- Mixed mode is the default: classic policies and ACP both apply, and the most restrictive result wins. Switch to ACP-only mode once you’ve migrated.
- Removing an environment from a group, or removing the rule from a group, doesn’t remove the policy from the environment. It keeps its last configuration until you remove it there.
From the field
A technology company called in a panic: close to 200 flows in their default environment were failing with data policy errors. Their only data policy was scoped elsewhere, and connectors they allowed manually kept “reverting.” In my experience the first thing to check is inheritance. The default environment had been in an environment group with an advanced connector policy and was later taken out, so it kept the group’s last allowlist. The clue was the Remove rule button on the environment’s own ACP panel. Once they removed the rule there, the environment fell back to classic data policies and the flows recovered.
09 Start with the operating model
Before anyone opens the admin center, I ask the team to agree on how governance should work. These are the questions I put to customers:
- Connector or usage? If a connector is approved, does every agent get to use it, or does each new use need review?
- Agent or component? Do you approve agents before they’re shared, or only the connectors, flows, and APIs beneath them?
- Trigger point. Is approval triggered when a connector is introduced, when a flow or API is created, or when an agent binds to it?
- Scope. What counts as an outbound integration: direct connector calls, flows invoked by agents, custom APIs, plug-ins, MCP servers?
- Enforcement. Design time (what makers can add), publish time (agent certification), or runtime (policy checked on every call)?
- Ownership. Who approves: a central CoE, environment admins, or business owners? And how do you trace who built what, what it calls, and what data leaves?
Then map the answers onto the platform’s three levels:
Tenant
Baseline
- Tenant isolation
- Tenant-wide classic data policy as the floor
- Custom connector and HTTP rules
Environment group
Tiers
- ACP allowlist per tier (dev, test, prod)
- IP firewall and cookie binding
- Agent authentication rules
Environment
Exceptions
- VNet enterprise policy
- Endpoint filtering for a specific project
- Gateway connections
From the field
A software company asked me for a tooling recommendation for governing Copilot outbound integrations. I sent back the six questions above before suggesting a single feature. Until the business answers them, any tooling choice is only a hypothesis, and approvals can be bypassed simply by reusing an already-approved connector.
For the broader environment and data policy design, see Environment Strategy and DLP: What I Recommend. For the tools that show you what’s actually in use, see The 2026 Governance Toolbox.
10 What to tell your network team
| When they ask… | What I’d tell them |
|---|---|
| “Send us the Copilot Studio IPs.” | There’s no fixed list. If you must filter by IP, use the regional service tags and automate updates. Better: tell us what the endpoint is and we’ll pick a private path. |
| “Our API must not be on the internet.” | VNet support with a private endpoint, if the connector is on the supported list. Otherwise, the on-premises data gateway. |
| “The partner only accepts one fixed IP.” | VNet support plus an Azure NAT gateway you own, or calls routed through a gateway server with a stable address. |
| “Only our offices should reach Dataverse and agents.” | IP firewall in audit-only mode first, then enforce. Add IP cookie binding. Remember the channel limits for agents. |
| “Stop data going to other tenants.” | Tenant isolation, for Entra-authenticated connectors, with explicit exceptions. |
| “Makers shouldn’t call arbitrary URLs.” | Endpoint filtering for HTTP and SQL, classic data policies for custom connectors, and an ACP allowlist for certified connectors and MCP servers. |
If the integration is an MCP server, the same rules apply, plus a few of its own. I cover those in Connecting MCP Servers to Copilot Studio. For who can talk to an agent and what identity it runs as, see Securing Agent Access.
11 Checklist
- Answer the six operating-model questions before choosing tools.
- Replace any hard-coded Power Platform IPs with regional service tags, refreshed automatically.
- Put authentication on every endpoint. Network filters are not identity.
- Use VNet support for private Azure and on-premises resources where the connector is supported, with a NAT gateway for controlled egress.
- Turn on the IP firewall in audit-only mode, review, then enforce at the environment group level.
- Run the cross-tenant report, then enable tenant isolation with explicit exceptions.
- Add endpoint filtering for HTTP and SQL, knowing it only checks static endpoints.
- Roll out ACP in mixed mode per environment group, and check inheritance when an environment changes groups.
Where I’d start
Next time the IP list request arrives, reply with a question instead of a spreadsheet: “Which system, which direction, and who needs to control it?” For most outbound cases the answer is VNet support with a NAT gateway, or the gateway where VNet doesn’t reach. For inbound, it’s the IP firewall in audit-only mode. Agree on the operating model first, and the tooling choices get much easier.
Happy to go deeper on any of this.
- K.G
← Back to “Environment Strategy and DLP: What I Recommend”
Sources
- Microsoft Learn: Power Platform URLs and IP address ranges (updated Aug 2026)
- Microsoft Learn: Managed connectors outbound IP addresses
- Microsoft Learn: Use IP firewalls for inbound connections to agents and Copilot Studio (preview)
- Microsoft Learn: IP firewall in Power Platform environments; Safeguarding Dataverse sessions with IP cookie binding
- Microsoft Learn: Cross-tenant inbound and outbound restrictions
- Microsoft Learn: Microsoft Azure Virtual Network support overview (updated Sep 2026); Set up virtual network support for Power Platform; Configure Virtual Network support for outbound connections from agents
- Microsoft Learn: SAP with Microsoft AI architecture: on-premises data gateway
- Microsoft Learn: Connector endpoint filtering (preview); Configure data policies for agents; Data policy example: block HTTP requests in agents
- Microsoft Learn: Advanced connector policies (updated Sep 2026); Power Platform blog: Advanced connector policies are generally available (June 2026)
Get new posts by email
Provider: your email provider
