Skip to content
Exedra Gate docs

Network IP rules

What IP restrictions do

IP restrictions let a workspace owner or admin limit team sign-in to approved networks. They apply to your team members at sign-in, after the password and second factor: a team member connecting from outside your allowed networks is refused a session even with correct credentials. They do not apply to investors, and they are an extra layer on top of the row-level isolation that always protects your data.

Enabling restrictions

Open /app/admin/audit and the Network access rules tab. Add at least one allowed network first, then switch enforcement on. Only owners and admins can see or change these settings, and every change is written to the access log.

Adding networks (CIDR entries)

A rule is a network range in CIDR form: 203.0.113.0/24 allows every address in that range, and a single address like 203.0.113.7 allows just that machine. IPv4 and IPv6 both work. The form checks the value as you type and stores it in canonical form; your current address is shown on the page so you can add the network you are on before turning enforcement on. Rules can be labelled, disabled temporarily, or removed, and each rule change is logged.

You cannot lock yourself out by accident

The behaviour is deliberately safest at the edges:

  • Enforcement off: nothing is checked, nothing changes.
  • Enforcement on with no active rules: everyone is still allowed in, and admins see a warning. An empty allow-list never bricks the workspace; add your network, then the rules bite.
  • Enforcement on with rules, and your address matches: you are in.
  • Enforcement on with rules, and your address does not match: the sign-in is refused.
  • Enforcement on with rules, but your address cannot be determined: the sign-in is refused and admins see a warning, because an active restriction should never silently wave someone through.

If a denial catches the wrong person, any admin on an allowed network can add their network or switch enforcement off; both actions are logged.

What a denied attempt looks like

The person sees a clear refusal at sign-in and their session is ended, on the server as well as in the browser. Your access log gains an "IP access denied" entry with the account, the time, and the address the attempt came from, on the workspace's tamper-evident record. Nothing about their account is changed; from an allowed network they can sign in normally.

Sovereign extensions

The third tab lists three modules for sovereign deployments: content disarm and reconstruction for uploads, signing with a hardware security module you operate, and forensic watermarking of document views. For most workspaces all three show as not provisioned, and that is the honest state: these modules only become available through a sovereign deployment engagement that wires them up, and a switch that looked on without anything enforcing it would be a false safety claim. Once a module is provisioned for your workspace, this tab is where you turn it on or off, and each flip is written to the access log.