Network policies overview

A network policy is a named, reusable list of the IP addresses and Classless Inter-Domain Routing (CIDR) ranges that can reach a Celigo endpoint, and the ones that can't. Create a policy once, then assign it to an MCP server, an API token, workspace-user sign-in, or end-user authentication. Before Celigo accepts a request, it checks the address the request came from against every policy that applies — a request from an address a policy doesn't allow is refused even when its credentials are valid. Nothing is restricted until you assign a policy.

This article explains when to use a network policy, how Celigo evaluates one, where you can assign one, what a blocked caller sees, and what Celigo records. To create a policy, see Create and manage network policies. To assign one, see Assign a network policy.

To work with network policies, go to Account (the avatar at the top of the page), select Security, and then select Governance from the left menu.

Feature availability:

• Only account owners and administrators can create, edit, delete, or assign network policies, in the UI and through the API. Users with Manage or Monitor access can't.
• A network policy belongs to the environment where you create it. In an account with multiple environments, each environment has its own policies and its own sign-in and end-user restrictions, and a policy can only be assigned to MCP servers and API tokens in its own environment.
• You can assign a network policy to MCP servers, API tokens, workspace-user sign-in, and end-user authentication. Inbound webhook listeners and API Builder or JavaScript APIs accept requests from any address.
• The Celigo support user is exempt from sign-in restrictions, so Celigo Support can still reach your account when you ask for help.

When to use a network policy

Any credential works from any location by default. An API token pasted into a chat window, a personal access token (PAT) on a lost laptop, or a phished password is as usable from a hotel network as from your office. An external identity provider's network zones or conditional access rules only cover SSO sign-in — they can't restrict API tokens, PATs, or Celigo credentials. A network policy covers those cases:

• Pin an MCP server to your corporate network. Assign the server a policy that allows your VPN and office ranges. Every call to it must come from those ranges, whether it carries an API token, a PAT, or an OAuth token, so a leaked token is useless anywhere else.
• Limit a vendor-facing API token to the vendor's published IP range. If the token leaks, it only works from the vendor's network.
• Require sign-in from your corporate network. Turn on IP-based access restriction for workspace users so credentials alone can't open the environment from an unrecognized location. This check applies to Celigo credentials and Google sign-in, which an identity provider can't restrict, and works alongside SSO and MFA.
• Limit where end users can sign in to your MCP servers. Turn on IP-based access restriction for end users so AI clients such as Claude or Cursor can only connect from approved networks.
• Block a range without loosening your allow list. During an incident, add the range to Blocked IPs. Blocked entries always win over allowed ones, so you can shut out one range while the rest of the policy stays unchanged.

Avoid restricting sign-in if your users work from home or travel without a VPN — they can't reach the environment until they connect from an approved network, and every failed attempt becomes a support ticket. If your identity provider already restricts SSO by network and everyone signs in through it, a sign-in policy adds little; put policies on MCP servers and API tokens instead, where the identity provider has no reach.

Network policies, authentication, and traffic limits

An MCP server's Access tab holds three controls that answer three different questions. A request must pass all three.

A traffic limit rejects calls above the limit. A network policy rejects every call from an address it doesn't allow, regardless of volume. For traffic limits, see MCP server traffic limits overview.

How Celigo evaluates a network policy

Celigo checks the address the request came from, read from the first entry in the request's X-Forwarded-For header. If your users reach Celigo through a proxy or VPN, that's the proxy's or VPN's public address — allow that address, not the users' internal ones.

For each policy that applies to a request, Celigo evaluates the lists in this order:

1. If the address matches an entry in Blocked IPs, the request is denied.
2. If Allowed IPs is empty, the request is allowed.
3. If the address matches an entry in Allowed IPs, the request is allowed.
4. Otherwise, the request is denied.

A policy with both lists empty allows every address — you can save it now and fill it in later. A policy with only Blocked IPs allows everything except the blocked ranges. A policy with only Allowed IPs allows those ranges and nothing else.

When more than one policy applies, the address must pass every one of them. For example, an API token with its own policy calling an MCP server that has a different policy must pass both, and an end user in an environment with an end-user restriction who calls a server with its own policy must pass both.

Entry format

Each entry is a single IP address or a CIDR range, in IPv4 or IPv6, and one list can hold both. When you save, Celigo stores a single address as a range of one: 203.0.113.5 becomes 203.0.113.5/32, and 2001:db8::1 becomes 2001:db8::1/128. Prefix lengths run from /0 to /32 for IPv4 and from /0 to /128 for IPv6. IPv4 octets with leading zeros, such as 010.0.0.1, are rejected.

Celigo compares an IPv4 address only against IPv4 entries, and an IPv6 address only against IPv6 entries — if your users reach Celigo over both, add both kinds of ranges. An IPv4 address that arrives in IPv4-mapped IPv6 form, such as ::ffff:203.0.113.5, is treated as the IPv4 address.

Where you can assign a network policy

What happens when a request is blocked

A blocked caller receives Access denied. and nothing more. The response never reveals the policy name, its entries, or which list matched — this is deliberate, so someone probing your account learns nothing about your security configuration. The HTTP status is 403, intentionally different from the 401 an invalid or expired credential receives, so whoever reads the error knows to check the network, not the credential. A blocked API call carries the body {"errors":[{"code":"access_denied","message":"Access denied."}]}, and a blocked MCP call carries a JSON-RPC error with code -32006 and the message Access denied..

A workspace user blocked at sign-in is signed in but shut out of the environment: an access denied message appears and no account data loads. The user can switch to another account or environment they belong to, or sign out. Retrying from an approved network succeeds without signing in again, and a user blocked while switching accounts stays in the account they came from. ⚠ VERIFY: the exact wording the blocked user sees in the browser — the message is transient and no dedicated string exists in the UI bundle; check on staging.

A blocked MCP call never runs the tool, the flow behind it, or its connection, and doesn't count toward traffic limits.

Sign-in and switch checks run at the moment of sign-in or switch — a session that was already open when you assigned the policy keeps working until the user next signs in or switches. Calls with API tokens, PATs, and end-user OAuth tokens are checked on every request.

Personal access tokens

A personal access token acts as the workspace user who created it, so it follows that user's sign-in restriction and has no Network policy field of its own. When IP-based access restriction is on for workspace users in an environment, every PAT created in that environment is checked against the same policy on every call, and a PAT used from outside the allowed ranges receives HTTP 403 with Access denied.. Assigning or changing the sign-in policy changes PAT enforcement at the same time.

What Celigo records

Every creation, edit, and deletion of a policy is written to the platform audit log, attributed to the user who made the change. An assignment change is recorded on the resource that holds it — the MCP server, the API token, or, for the two restrictions, the account settings.

Each workspace-user sign-in or account switch that a policy denies is written to the account's audit log as a signinDenied event, with the user, the time, the sign-in method, the checked address in the IP address field, and IP address not permitted by network policy in the Denial reason field. ⚠ VERIFY: the audit log's display label for the signinDenied event.

Each MCP call that a server's policy denies appears in that server's request logs as an error with status 403. The log record also carries the caller, the authentication method, the client address, and the reason network_policy. ⚠ VERIFY: whether the request log detail panel displays these denial fields. To open the request logs, see Monitor requests that exceed MCP server traffic limits.

Calls blocked by an API token's policy, PAT calls blocked by the sign-in policy, and end-user sign-ins blocked by the end-user policy are recorded in Celigo's internal logs only — they don't appear in a log you can open. If a caller reports Access denied. from one of these, compare their public address with the assigned policy.

Limits and unsupported behavior

• 100 policies per environment. Creating the 101st fails.
• 200 entries per list. Allowed IPs and Blocked IPs each hold up to 200 entries.
• One policy per assignment. An MCP server, an API token, the sign-in restriction, and the end-user restriction each hold one policy. To allow several ranges, put them in one policy. You can assign the same policy to any number of servers, tokens, and restrictions.
• IP addresses only. Host names, domains, and countries aren't supported.
• No per-user or per-group policies. The sign-in restriction applies to every workspace user of the environment, and the end-user restriction applies to every end user.
• Webhooks and APIs aren't covered. Inbound webhook listeners and API Builder or JavaScript APIs accept requests from any address.
• Changes take up to 30 seconds. A new or edited policy, or a changed assignment, applies within about 30 seconds.
• Existing sessions aren't ended. A sign-in restriction applies at the next sign-in or account switch.
• A policy in use can't be deleted from the UI. Unassign it first. The API can force the deletion, which removes every assignment. A deleted policy stays in the Recycle bin for 30 days and can be restored.
• The support user bypasses sign-in restrictions. You can't restrict Celigo Support by IP address.

Frequently asked questions

Can I lock myself out?

Yes, if you restrict sign-in with a policy that doesn't include your own address. Before you save, Celigo checks your current address against the selected policy and warns you: Your current IP address (203.0.113.5) is not allowed by this policy. Saving may lock you out. The warning doesn't stop the save. If you do lock yourself out, sign in from an approved network, ask another administrator on an approved network to change the policy, or contact Celigo Support, whose access is exempt.

Do I have to assign a policy to every MCP server?

No. A server with no policy accepts calls from any address, which is how every server behaves until you assign one. The Network policy field on a server is optional; only the sign-in and end-user restrictions require a policy, and only while they're turned on.

What happens when I edit a policy that's assigned?

The change applies to every assignment within about 30 seconds. There's no separate publish step.

What happens when I delete a policy?

You can only delete a policy after removing every assignment, so the servers, tokens, and restrictions it protected are already unrestricted — not blocked — by the time you delete it. The deleted policy moves to the Recycle bin, where you can restore it for 30 days before Celigo purges it.

Do PATs get their own policy?

No. A PAT follows the workspace-user sign-in restriction of the environment it was created in. See Personal access tokens.

Does the end-user restriction apply to users who sign in through an external identity provider?

Yes. The end-user policy is checked each time an end user's OAuth token is used against an MCP server, whichever identity provider issued the sign-in.

Does a policy in production apply to my sandbox?

No. Each environment has its own policies and its own sign-in and end-user restrictions, and a policy can only be assigned within its environment.

Why did my request get a 403 and not a 401?

A 401 means the credential failed. A 403 with Access denied. means the credential was accepted and the address was refused — check the public address the call left from against the assigned policies.

Related articles

• Create and manage network policies
• Assign a network policy
• Set up authentication for an MCP server
• Managing API tokens
• Configure end user authentication