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:
| Category | Scope Value | Endpoint | Description |
|---|---|---|---|
| API | api | api.getmontecarlo.com | Restricts access to the Monte Carlo API |
| Airflow Callbacks | airflowcallbacks | integrations.getmontecarlo.com/airflow/callbacks | Restricts access to the Airflow callback endpoint |
| Azure DevOps Webhook | azuredevopswebhook | integrations.getmontecarlo.com/gateway/azure-devops | Restricts access to the Azure DevOps webhook endpoint |
| Circuit Breaker | circuitbreaker | integrations.getmontecarlo.com/checkpoint/circuit-breaker | Restricts access to the Circuit Breaker endpoint |
| Databricks Metadata | databricksmetadata | integrations.getmontecarlo.com/databrick/metadata | Restricts access to the Databricks metadata endpoint |
| Databricks Webhook | databrickswebhook | integrations.getmontecarlo.com/webhooks/databricks | Restricts access to the Databricks webhook endpoint |
| MCP | mcp | integrations.getmontecarlo.com/mcp/ | Restricts access to the MCP Server endpoint |
| OpenTelemetry | opentelemetry | integrations.getmontecarlo.com/otel | Restricts access to the OpenTelemetry collector endpoint |
| SCIM v2 | scim_v2 | integrations.getmontecarlo.com/scim/v2/ | Restricts access to the SCIM provisioning endpoint |
| Global | global | All of the above | Restricts all scopes listed above |
Network Access Control is supported on both global and regional endpoints
For example,
api.getmontecarlo.comandapi.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 scopeSetting a Network Access Control List on the
globalscope 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 behaviorThe
saveNetworkAccessControlmutation 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 theallowedIpsarray 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.10or198.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:
Updated about 23 hours ago
