Security

IP allowlist

Name the networks your workspace answers from and everything else stops, for browser sessions and API keys alike. A key handed to an agent running outside your office network stops working exactly the way a browser session does, which is the control an IT reviewer is actually asking for.

What it covers

The check runs once, on every authenticated request, so it reaches every path at the same time: the app, the CLI, the REST API and any ek_ API key. There is nothing to turn on per route and nothing that can be left out by accident.

Set the list

In the app: Settings, Security, Network access, which shows the address you are on right now and offers it as the first entry. Over the API:

curl -s -X PUT https://api.engramdynamics.org/enterprise/ip-allowlist \
  -H "Authorization: Bearer <your key>" \
  -H "Content-Type: application/json" \
  -d '{"cidrs": ["203.0.113.0/24", "198.51.100.7", "2001:db8::/32"]}'

{
  "cidrs": ["203.0.113.0/24", "198.51.100.7/32", "2001:db8::/32"],
  "your_ip": "203.0.113.42",
  "your_ip_allowed": true
}

A bare address is accepted and stored as a single-host network, because "let my office in" is usually typed as one address. Ranges are normalized on the way in, so 203.0.113.5/24 is stored and shown back as 203.0.113.0/24. Anything that is not an address or a range is a 400 that quotes what you typed. IPv4 and IPv6 both work.

Read the current list, and the address we see you on, with:

curl -s https://api.engramdynamics.org/enterprise/ip-allowlist \
  -H "Authorization: Bearer <your key>"

Reading is open to any workspace admin on any plan. Writing is what the plan table gates.

The lockout guard

Saving a list your own address falls outside would lock your company out of its own account, and the next request, including the one that would undo it, would be refused. So the write refuses first and tells you what it saw:

{
  "detail": {
    "error": "ip_lockout",
    "message": "This list does not include the address you are on right now (203.0.113.42), so saving it would lock this workspace out. Add your address, or confirm you meant to.",
    "your_ip": "203.0.113.42"
  }
}

The case is real, though: an admin at home configuring the office range means it. Send "confirm_lockout": true to go ahead anyway.

curl -s -X PUT https://api.engramdynamics.org/enterprise/ip-allowlist \
  -H "Authorization: Bearer <your key>" \
  -H "Content-Type: application/json" \
  -d '{"cidrs": ["203.0.113.0/24"], "confirm_lockout": true}'

What a blocked request sees

A request from outside the list is a 403 that names the address it came from, so the person hitting it can tell you what to add rather than guessing:

{
  "detail": {
    "error": "ip_not_allowed",
    "message": "This workspace only accepts requests from the networks its admin allowed. We saw this request come from 198.51.100.99.",
    "your_ip": "198.51.100.99"
  }
}

An address we cannot read at all is refused too, with a list configured. An allowlist that quietly stopped applying whenever the address was unreadable would be worse than not having one.

How your address is read

The address is taken as the trusted edge saw it, counting in from the right of the forwarding chain, which is the half a client cannot forge. A header a caller sets themselves never walks through the allowlist. The guarantee rests on every request reaching us through the load balancer, which is how the platform is deployed: the application tasks are not reachable directly.

Turning it off

An empty list clears the restriction and is always allowed, whatever the plan:

curl -s -X PUT https://api.engramdynamics.org/enterprise/ip-allowlist \
  -H "Authorization: Bearer <your key>" \
  -H "Content-Type: application/json" \
  -d '{"cidrs": []}'

Every change writes an enterprise.ip_allowlist_set row to the audit log, carrying the list that was saved and whether a lockout was confirmed.

Next

Your own KMS key is the other Enterprise control. API keys and scopes covers narrowing what a credential can do, which pairs with narrowing where it can be used from.