Alex Grover

SharePoint CSA / App Developer / AI Enthusiast

3 minute read

Unlocking Secure Agentic Access: Restricting Copilot Studio Agents to Snowflake with IP Whitelisting

Picture this: You’ve just built a powerful Copilot Studio agent—one that can surface insights from your enterprise’s Snowflake data platform, driving real-time decisions for your business. But there’s a catch: your security team insists that Snowflake must only accept connections from whitelisted IPs. Domains? Not supported. And your agent, running in the cloud, could be anywhere. How do you bridge this gap—delivering seamless, secure access without opening the floodgates?

Welcome to the world of IP restriction for Copilot Studio agents connecting to Snowflake. Here’s how we solved it for a major enterprise scenario, and how you can too.

The Challenge: Domains Not Allowed, Regions Matter

Snowflake, like most enterprise data platforms, lets you restrict inbound access by IP address—but not by domain name. This means you can’t simply whitelist “powerplatform.microsoft.com” or similar. Instead, you need to know the exact outbound IP ranges that your Copilot Studio agent will use when connecting to Snowflake.

But here’s the twist:

  • Power Platform (and thus Copilot Studio) runs in multiple Azure regions
  • Each region has its own set of outbound IPs
  • You must map your environment’s region to the correct Azure IP ranges, then configure Snowflake to accept only those

Step 1: Discover Your Power Platform Environment’s Region

Before you can whitelist anything, you need to know where your Copilot Studio agent is running. Here’s how:

  1. Go to the Power Platform Admin Center: Navigate to https://admin.powerplatform.microsoft.com
  2. Select your environment
  3. In the details pane, look for the “Region” field (e.g., “Europe”, “UK”, “US”)

Why this matters: Each region maps to specific Azure datacentres, which in turn have unique outbound IP ranges.

Reference: Power Platform regions overview

Step 2: Map Your Region to Azure Outbound IP Addresses

Now, you need to find the outbound IPs for your region. Microsoft publishes these as “Service Tags” in a downloadable JSON file, updated weekly.

Manual Method

  1. Download the latest Azure IP Ranges and Service Tags
  2. Open the JSON file and search for your region’s service tags. For example, if your region is “Europe”, look for:
    • AzureConnectors.NorthEurope
    • AzureConnectors.WestEurope

Automated Method (PowerShell)

You can use the provided script (Get-PPRegionIPs.ps1) to extract the relevant IPs for your region. Here’s how it works:

Script Highlights:

  • Maps friendly region names (e.g., “UK”, “Europe”) to Azure region codes
  • Reads the JSON file and extracts all IP prefixes for the relevant service tags
  • Outputs the list, and optionally saves it to a file

Usage Example:

.\Get-PPRegionIPs.ps1 -Region "Europe" -ServiceTagsFile "ServiceTags_Public_20251006.json"

This will print all IPs for the “Europe” region’s connectors, ready for whitelisting in Snowflake.

Script Source: Get-PPRegionIPs.ps1 Provided by Alex Grover

References:

Step 3: Configure Snowflake Network Policy

With your list of IPs in hand, it’s time to lock down Snowflake.

Snowflake’s Modern Approach (2024+)

  • Use “Network Rules” and “Network Policies” for flexible, scalable management
  • Network Rules group IPs (or ranges) logically
  • Network Policies reference these rules and are applied at the account, user, or integration level

Example Workflow

  1. Create a Network Rule: 
    CREATE NETWORK RULE my_powerplatform_ips
  MODE = INGRESS
  TYPE = IPV4
  VALUE_LIST = ('13.69.171.0/32', '20.82.159.224/32', ...); -- Add all IPs from your script
  2. Create a Network Policy: 
    CREATE NETWORK POLICY powerplatform_policy
  ALLOWED_NETWORK_RULE_LIST = ('my_powerplatform_ips');
  3. Apply the Policy: 
    ALTER ACCOUNT SET NETWORK_POLICY = powerplatform_policy;

Only connections from the specified IPs will be allowed.

References:

Why Not Use Domains or Hostnames?

Snowflake does not support domain-based restrictions for inbound connections—only IP addresses or private endpoint IDs. This is a common enterprise security requirement, and it’s why the mapping process above is essential.

Pro Tips and Gotchas

  • Update Regularly: Microsoft updates IP ranges weekly. Automate your process to refresh the allowed list
  • Audit and Monitor: Test your agent’s connectivity after changes. Use Snowflake’s access logs to verify only allowed IPs are connecting
  • Private Link (Advanced): For even tighter security, consider Azure Private Link integration, which restricts access to private endpoints only

Conclusion: Secure, Scalable, and Agentic

By following these steps, you can confidently enable Copilot Studio agents to access Snowflake—securely, at scale, and in line with enterprise best practices. The process may seem daunting, but with the right tools and a clear understanding of the moving parts, you’ll empower your agents to deliver value without compromising on security.

Ready to unlock the full potential of agentic data access?

Start with region discovery, automate your IP mapping, and let Snowflake’s network policies do the heavy lifting.

References & Further Reading

You May Also Enjoy