IP Allow List
What is an IP Allow List?
An IP allow list restricts access to a fixed set of IP addresses and CIDR ranges. Anything arriving from an address that is not on the list is refused, even with valid credentials.
This is a containment control rather than an authentication one. It does not stop a credential being stolen — it makes a stolen credential useless from anywhere except your own network, which is usually the difference between an incident and a non-event.
IP allow lists are available on Enterprise plans, and are currently in open beta.
Two separate lists
Report URI has two independent allow lists. They are configured in different places, stored separately, and do different jobs — turning one on does not affect the other.
| Team Allow List | API Key Allow List | |
|---|---|---|
| Restricts | Access to the teams you own | Use of your API key |
| Configured at | Settings | API / MCP |
| Applies to | Everyone who is a member of your teams | Scripts, integrations and MCP clients |
Most organisations want both, but they are worth thinking about separately: the addresses your staff browse from are rarely the addresses your CI pipeline calls the API from.
The team list is set once, by the owner
You set the list on your own account, and it applies to every team you own — there is no per-team list. Each team member is checked against the owner's list, not their own. So the list has to cover the addresses everyone in your teams works from, not just yours.
It does not restrict personal accounts. Your own personal account, and your members' personal accounts, stay reachable from anywhere. The control protects the shared team data, which is where the data actually lives.
Setting up the Team Allow List
Go to the Settings page and find the IP Allow List panel.
The panel shows your current IP address as the application sees it. Start from that value — if you are behind a proxy, VPN or corporate egress gateway, the address the application sees is often not the one your device thinks it has, and getting this wrong is the single most common way to lock yourself out.
Enter one entry per line. Both individual addresses and CIDR ranges are accepted, in IPv4 and IPv6:
203.0.113.0/24
2001:db8::/32
198.51.100.5
Then switch Restrict account access to listed IPs on and save.
The list takes effect immediately, for you and for every member of every team you own. Check it covers your colleagues' addresses, not just your own, before you switch it on — otherwise their next page load bounces them out of the team.
Setting up the API Key Allow List
Go to the API / MCP page. The API Key IP Allow List panel appears once an API key exists, since the list governs a key.
The format is identical — one address or CIDR range per line. Switch it on and save, and the key stops working from anywhere else.
Point it at wherever your automation actually runs: your CI runners' egress addresses, a NAT gateway, or the fixed address of the server making the calls. If you connect an MCP client from a laptop, remember that address needs covering too.
What happens when access is refused
Nobody gets locked out of Report URI. The team list moves people out of the team rather than out of the product.
When someone loads a page while switched into a restricted team from an address that is not on the list, they are switched to their personal account and shown a message telling them the IP address the application saw. That address is the one to add if it should have been allowed. The event is also written to the owner's Audit Trail, so you can see who was refused and from where.
They can switch back into the team the moment they are on an allowed address. Nothing is disabled and nothing needs resetting.
This also means you cannot lock yourself out of your own settings. The Settings page lives on your personal account, which is never restricted, so you can always go back and correct or switch off a list that turned out to be wrong — including from the machine that was just refused.
A refused API call simply fails; you fix the list from the web interface, which the API key list does not govern.
The list does not lapse with your plan
If an Enterprise subscription ends while an allow list is switched on, the list stays in force. A security control that silently stopped working on a billing event would be worse than one that keeps running. The settings panel stays available to you so you can turn it off deliberately, even though the plan no longer includes the feature.
Choosing what to put on the list
A few things worth checking before you commit a list:
- Egress, not ingress. You need the addresses your traffic leaves from, which are frequently not the addresses your services are reached on.
- Watch for dynamic addresses. Residential and small-office connections often change address without warning. Prefer a VPN with a fixed egress address over listing a home IP.
- IPv6. If your network has IPv6 enabled, connections may arrive over it even when you tested on IPv4. List both, or you will see intermittent refusals that are hard to reproduce.
- Keep it current. Add a review of the list to whatever process you already run for offboarding and network changes.