Network Policies

A network policy decides which callers are allowed to reach a server, based on where the request comes from. You build a policy once, then assign it to the MCP servers you want it to protect.

Network policy is the first control the gateway applies — before it checks who the caller is. A caller from a blocked network is turned away whether or not they hold a valid credential.

Quick Start: What do you want to do?

I want to...	Go to
Allow only my office or VPN addresses	Build a policy
Understand why everything got blocked	The Block All rule
Watch who would be blocked, without blocking	Choose an action
Apply a policy to one server	Assign a policy to a server
Know what a blocked caller sees	What a blocked caller gets
Find the addresses the gateway connects from	IP addresses

---

How a policy works

A policy is an ordered list of rules. The gateway walks the list from the top and applies the first rule that matches — everything below it is ignored. Each rule pairs a condition with an action.

Every policy ends with a rule named Block All, which matches everything. You cannot rename it, reorder it, change its action or delete it. It is what makes a policy deny-by-default: anything your rules did not explicitly allow reaches Block All and is refused.

Build a policy

Go to Security Guardrails → Network Policies and select Policy.

1. Give the policy a Name, and optionally a Description.
2. Leave Enabled on. A disabled policy is not evaluated at all.
3. Select Add Rule, then Add Condition to choose what the rule matches on.
4. Pick the rule's Action.
5. Add more rules and use the up and down arrows to order them. Remember the first match wins.
6. Check the Policy Summary at the bottom, which reads the whole policy back to you as plain sentences, then Save.

Choose a condition

Condition	Matches on	Use it to
IP/CIDR	One or more addresses or ranges, for example 10.0.0.0/8 or 203.0.113.7	Allow your office, VPN or data-centre ranges
Authenticated Users	Whether the caller has been added to the AI Gateway	Allow only people your organization has onboarded

A NOT switch inverts any condition, so you can write "anything that is not these addresses". With more than one IP/CIDR entry you also choose ANY (match if one entry matches) or ALL.

A bare address is treated as a single host. Entering 0.0.0.0/0 to mean "everywhere" also covers IPv6 addresses.

Choose an action

Action	What happens
Allow	The request continues to the next control
Block	The request is refused immediately
Alert	The request is allowed through and recorded

Alert does not block anything. Use it to see who a rule would catch before you switch it to Block.

The Block All rule

This is the single most common surprise. A new policy is deny-by-default, so the moment you assign one, anything your rules do not explicitly allow stops working.

Before assigning a policy, make sure your allow rules cover:

• the people and agents who use the server today
• any automation, CI job or monitoring that calls it
• every office, VPN and cloud range those callers come from

A safe way to find out is to build the policy with your allow rules set to Alert instead of Block, assign it, and watch for a while. Alert lets everything through, so you learn who is calling without cutting anyone off.

Assign a policy to a server

A policy does nothing until a server uses it.

1. Open the server from the MCP Registry.
2. Select the Network Policy tab.
3. Choose a policy, then Apply Changes.
4. When prompted, Deploy Now to push the change to the server.

A server with no policy of its own uses the tenant default policy — the one marked Default in the list. So "no policy selected" does not mean "no policy applied". To change which policy is the default, use Set as Default from the row menu in the policy list.

note

Agent Personas do not carry their own network policy assignment. Traffic through a persona is covered by the tenant default policy only.

What the gateway ships with

Two policies exist from the start and are marked System:

Policy	What it does
Allow All	Allows traffic from any source. This is the default policy unless you change it.
Authenticated IP Binding	Allows a request only when the caller's address matches the address they authenticated from.

What a blocked caller gets

A blocked caller receives HTTP 403 with a short message saying access was denied by network policy.

The message deliberately does not name the policy or the rule — that detail would tell an unwanted caller how your rules are shaped. The full decision, including which rule matched, is recorded for you in the audit trail. See Observability.

Real-world examples

Lock a finance server to the corporate VPN

Order	Rule	Condition	Action
1	Allow VPN	IP/CIDR 10.8.0.0/16	Allow
2	Block All	everything	Block

Allow two offices, and watch everyone else first

Order	Rule	Condition	Action
1	Allow London	IP/CIDR 203.0.113.0/24	Allow
2	Allow Austin	IP/CIDR 198.51.100.0/24	Allow
3	Watch everyone else	NOT IP/CIDR 203.0.113.0/24, 198.51.100.0/24 (ANY)	Alert
4	Block All	everything	Block

Rule 3 never blocks. It records callers from anywhere else so you can see who you would cut off, and you can delete it once you are confident.

What to ask your IT team

Ask for	Why you need it
The public egress ranges for each office and VPN	These are the addresses your policy must allow
The egress range of any cloud environment that calls the gateway	CI jobs and services are easy to forget and break loudly
Whether those ranges are static	A range that changes will silently start failing
Who owns changes to them	So you hear about a renumbering before it blocks traffic

Tips

• Assign with Alert first, switch to Block later. It turns a risky change into an observation.
• Allow before you block. Rules are first-match, so an Allow rule placed below a Block rule never runs.
• Say what a rule is for in its name. "Allow London office" is far easier to audit a year later than "Rule 3".
• Check the tenant default. Changing which policy is default silently changes behaviour for every server that has not picked one.
• Keep the list short. A policy with twenty overlapping rules is hard to reason about and easy to get wrong.