Network Access Control

Network Access Control Lists allow you to restrict access to Monte Carlo's API and certain endpoints by IP address. When configured, only requests originating from IPs in the allowlist are permitted for the specified scope. This feature is managed via the GraphQL API using three operations: list, save (create or update), and delete.

👍

Please note that this is different from the network controls and options used for data collection with most integrations, such as IP allowlisting, PrivateLink, and Agents/Data Stores.

See the networking documentation here for more details.

Scopes

Each Network Access Control List is associated with a scope that determines which endpoint it restricts. The following scopes are available:

CategoryScope ValueEndpointDescription
APIapiapi.getmontecarlo.comRestricts access to the Monte Carlo API
Airflow Callbacksairflowcallbacksintegrations.getmontecarlo.com/airflow/callbacksRestricts access to the Airflow callback endpoint
Azure DevOps Webhookazuredevopswebhookintegrations.getmontecarlo.com/gateway/azure-devopsRestricts access to the Azure DevOps webhook endpoint
Circuit Breakercircuitbreakerintegrations.getmontecarlo.com/checkpoint/circuit-breakerRestricts access to the Circuit Breaker endpoint
Databricks Metadatadatabricksmetadataintegrations.getmontecarlo.com/databrick/metadataRestricts access to the Databricks metadata endpoint
Databricks Webhookdatabrickswebhookintegrations.getmontecarlo.com/webhooks/databricksRestricts access to the Databricks webhook endpoint
MCPmcpintegrations.getmontecarlo.com/mcp/Restricts access to the MCP Server endpoint
OpenTelemetryopentelemetryintegrations.getmontecarlo.com/otelRestricts access to the OpenTelemetry collector endpoint
SCIM v2scim_v2integrations.getmontecarlo.com/scim/v2/Restricts access to the SCIM provisioning endpoint
GlobalglobalAll of the aboveRestricts all scopes listed above
👍

Network Access Control is supported on both global and regional endpoints

For example, api.getmontecarlo.com and api.eu1.getmontecarlo.com.

Scope precedence

When a request is received, Monte Carlo first checks for a scope-specific access control list. If no scope-specific rule exists for that endpoint, it falls back to the global configuration. This means a scope-specific rule takes precedence over the global rule.

❗️

Global scope

Setting a Network Access Control List on the global scope restricts all endpoints listed above. If you set a global restriction, only IPs in the global allowlist will be able to access any scope that does not have its own scope-specific rule.

Usage

👍

How Can I Use the API?

You can access the API through the API Explorer in the Monte Carlo UI. Learn more about the API Explorer here.

Alternatively, you can generate an API key and make API calls using tools such as cURL or Postman

Listing Network Access Control Lists

Use the getNetworkAccessControlLists query to retrieve all configured restrictions and their allowed IPs.

query GetNetworkAccessControlLists {
  getNetworkAccessControlLists {
    scope
    allowedIps {
      value
      description
    }
  }
}
{
  "data": {
    "getNetworkAccessControlLists": [
      {
        "scope": "api",
        "allowedIps": [
          {
            "value": "203.0.113.10",
            "description": "Office VPN"
          },
          {
            "value": "198.51.100.0/24",
            "description": "CI/CD pipeline"
          }
        ]
      }
    ]
  }
}

Creating or updating a restriction

Use the saveNetworkAccessControl mutation to create a new restriction or update an existing one for a given scope.

🚧

Replace behavior

The saveNetworkAccessControl mutation replaces the entire allowlist for the specified scope. If you want to add a new IP to an existing list, you must include all previously allowed IPs in the allowedIps array along with the new one.

👍

Network Access Control applies to the API and integration endpoints only — not the Monte Carlo UI. If you save a restriction that excludes your current IP, you can still log into the Monte Carlo web application and use the API Explorer to update or remove the restriction.

mutation SaveNetworkAccessControl {
  saveNetworkAccessControl(
    scope: api
    allowedIps: [
      { value: "203.0.113.10", description: "Office VPN" },
      { value: "198.51.100.0/24", description: "CI/CD pipeline" }
    ]
  ) {
    saved
  }
}
{
  "data": {
    "saveNetworkAccessControl": {
      "saved": true
    }
  }
}

Parameters:

  • scope (required) — One of the scope values from the table above.
  • allowedIps (required) — Array of IP entries:
    • value (required) — An IP address or CIDR range (e.g., 203.0.113.10 or 198.51.100.0/24).
    • description (optional) — A human-readable label for the IP entry.

Deleting a restriction

Use the deleteNetworkAccessControl mutation to remove the entire allowlist for a scope, restoring open access to that endpoint.

mutation DeleteNetworkAccessControl {
  deleteNetworkAccessControl(scope: api) {
    deleted
  }
}
{
  "data": {
    "deleteNetworkAccessControl": {
      "deleted": true
    }
  }
}

Parameters:

  • scope (required) — The scope to remove the restriction from.

Examples

Restricting API access to office IPs

To restrict API access so only your office network can make API calls:

Step 1: Save the restriction with your office IPs.

mutation SaveNetworkAccessControl {
  saveNetworkAccessControl(
    scope: api
    allowedIps: [
      { value: "203.0.113.10", description: "Office - Main" },
      { value: "203.0.113.11", description: "Office - Backup" }
    ]
  ) {
    saved
  }
}

Step 2: Verify the restriction is in place.

query GetNetworkAccessControlLists {
  getNetworkAccessControlLists {
    scope
    allowedIps {
      value
      description
    }
  }
}

Restricting a single integration

To restrict only the Circuit Breaker endpoint to requests from a specific Airflow instance:

mutation SaveNetworkAccessControl {
  saveNetworkAccessControl(
    scope: circuitbreaker
    allowedIps: [
      { value: "10.0.1.50", description: "Airflow production instance" }
    ]
  ) {
    saved
  }
}

This does not affect access to other endpoints like the API or other integrations.

Setting a global restriction

To restrict all endpoints at once using the global scope:

mutation SaveNetworkAccessControl {
  saveNetworkAccessControl(
    scope: global
    allowedIps: [
      { value: "203.0.113.0/24", description: "Corporate network" }
    ]
  ) {
    saved
  }
}

With this in place, any scope that does not have its own scope-specific rule will only accept requests from the corporate network. If you later add a scope-specific rule (e.g., for circuitbreaker), that scope will use its own allowlist instead of the global one.

To remove the global restriction:

mutation DeleteNetworkAccessControl {
  deleteNetworkAccessControl(scope: global) {
    deleted
  }
}

FAQs

Are controls on a per–Monte Carlo account (workspace) basis?

Yes. Controls are applied per Monte Carlo account (workspace). If you have multiple accounts, you can manage controls independently for each one.

How long does it take for changes to apply?

Updates to allowlists typically take effect within a few minutes, generally within 5 minutes. In some cases, propagation may take slightly longer due to caching or network distribution delays.

What is the behavior if there are no network rules or access controls set?

If no IPs are explicitly allowlisted, access is permitted from any IP address.

Authentication (for example, token verification) is still always enforced, and all traffic is transmitted over HTTPS

What IP format is supported?

Both individual IP addresses (e.g., 203.0.113.10) and CIDR notation (e.g., 198.51.100.0/24) are supported.

What happens if I set a restriction that excludes my current IP?

You will not be fully locked out. Network Access Control restrictions only apply to API and integration endpoints, not the Monte Carlo web application. You can always log into the Monte Carlo UI and use the API Explorer to update or remove the restriction.

How does the global scope interact with scope-specific restrictions?

Monte Carlo checks for a scope-specific rule first. If one exists, it is used. If no scope-specific rule is found, the global rule is checked. This means scope-specific rules take precedence over the global rule.

The global scope is used as a fallback when no scope-specific rule exists.

Does this affect the Monte Carlo UI?

Network Access Control Lists apply to the API and integration endpoints only. They do not restrict access to the Monte Carlo web application UI.

To restrict access to the Monte Carlo UI, we recommend configuring IP restrictions directly in your SSO identity provider.

How do I add a new IP to an existing restriction without removing the old ones?

First, query the current list using getNetworkAccessControlLists to get all existing IPs for the scope. Then call saveNetworkAccessControl with the full list of IPs (existing plus new). The save operation replaces the entire list, so you must include all IPs you want to keep.

API Documentation

Detailed documentation for these operations is available in our API documentation: