Replace the workspace's network allowlist

Replace the list of CIDR ranges for this workspace.

This is a replace, not an append. The list you send becomes the whole list, and sending an empty list clears it.

Every entry is validated as a CIDR before anything is written, so one bad entry refuses the whole request and leaves the stored list untouched.

The change is recorded in the audit log.

Writes only settings.allowlist_cidrs, via jsonb_set on that one path.

Used to read the whole settings blob, mutate it in Python and write it back whole. That was the same shape PATCH /tenants/me had, and the same defect: a concurrent write to any other key in settings (onboarding, spend caps, deployment mode) committing between this route's read and its write was silently reverted. Measured 19/25 rounds losing an accepted allowlist this way, with security.allowlist.updated still emitted to the audit log: a network control the trail said was applied and was not. jsonb_set on {allowlist_cidrs} cannot touch a key it was not told to, independent of what else is racing it.

Tenancy: the request is scoped to one workspace, and the credential presented is what selects it. A caller with no membership in that workspace is refused with 404, which is indistinguishable from a workspace that does not exist.

Authorisation: admin or owner. An editor or viewer receives 403 insufficient_role.

Access: Authorization: Bearer carrying either a realm access token or an API key. A key must hold the workspace-admin:write scope, and the workspace role of the person who owns it must meet the floor above.

Response Body

curl -X PUT "https://example.com/v1/workspace/security/allowlist" \  -H "Content-Type: application/json" \  -d '{}'

{}