> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dataerai.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Geographic access fences (geobounds)
> Restrict a project to a set of allowed regions. A geobound bounds every read — including public links and system admins — and does not apply outside the fence.
A **geobound** is a project-level geographic access fence. When a project enables its geobound, every read of the project — and of the collections, assets, and datasets it owns — must satisfy the fence, based on the viewer's current region, their institutional affiliation, or operator-maintained country lists.
This is stronger than [public sharing](/sharing/public): a public grant normally lets any signed-in user with the link view a project, but a geobound keeps that data inside its allowed regions even for public links.
## What a geofenced project means
* **Every read is bounded.** Signed-in public-link readers, directly-granted users, organization members, and even platform administrators must all be inside the fence to read the project. There is no role that sees through it.
* **No bypass.** There is no request-time override. If a fence is misconfigured, recovery is a deliberate policy edit by an operator (see [Geobounds operations](/account/geobounds-operations)) — not an in-app unlock.
* **Fail-closed.** When the viewer's region can't be determined, the request is treated as *outside* the fence and denied (unless the project owner explicitly opts out of fail-closed).
A geobound applies to **you too**. If you fence a project to a region you aren't currently in, you can lock yourself out of your own project. Recovering requires an operator to edit the policy — there is no self-service override. Confirm your allowed regions before enabling.
## The public-access fence warning
When a project's geobound is enabled, its permissions panel shows a **shield** warning beside the **Make publicly available** toggle:
> Geofenced — public access is limited to the project's allowed regions and does not apply outside the geofence.
This is your reminder that, on a fenced project, "public" no longer means "any signed-in user with the link" everywhere — it means *inside the fence*.
## Configure a project's geobound
Geobound controls live in the project create / edit form, under **Geographic access (geobounds)**.
Create a project with **New project**, or open an existing project's **Settings** to edit it.
Turn on the **Geographic access (geobounds)** toggle. The dependent fields appear.
Pick a **Basis**:
| Basis | The fence is satisfied by |
| ------------------------------ | --------------------------------------------------------------- |
| **IP country** | The country derived from the viewer's network address. |
| **Affiliation country** | The country of the viewer's verified institutional affiliation. |
| **IP or affiliation country** | *Either* signal placing the viewer inside the fence. |
| **IP and affiliation country** | *Both* signals placing the viewer inside the fence. |
Choose a **country rule**, then add countries with the searchable
multi-select — type a country name or ISO-2 code and click to add it; each
selection appears as a removable chip.
| Country rule | Effect |
| -------------- | ------------------------------------------------------------------------------------------------------ |
| **Pass rule** | An *allowlist* — access is permitted **only** from the selected countries; everywhere else is blocked. |
| **Block rule** | A *denylist* — access is permitted from **everywhere except** the selected countries. |
Switching between Pass and Block keeps the countries you already picked, so
you can flip the rule without re-selecting. You can additionally layer the
operator-maintained **Allowed country set** and **Denied country set**
presets described below; allow lists combine and deny lists always block.
**Block VPNs and anonymizers** denies access from detected VPN / proxy networks. **Fail closed** denies access when the region can't be determined (rather than allowing it). Both are **on by default** — leave them on unless you have a specific reason not to.
## Allow vs deny country sets
A **country set** is an operator-maintained, versioned list of countries. Each set is one of two kinds:
* **Allow** — permits *only* the listed countries (for example a geographic grouping like the EEA). A viewer outside the list is denied.
* **Deny** — blocks the listed countries no matter what else allows them. Government / sanctions / export-control lists (for example OFAC or ITAR §126.1) are deny-kind sets.
The combined rule is: a viewer in country `c` is permitted when (no allow rule applies **or** `c` is in your pass-rule countries or an allow-kind set) **and** `c` is not in your block-rule countries or any deny-kind set. **Deny always wins** — a block-rule country (or a deny-kind set) is refused even if an allow rule would otherwise permit it. Country sets are maintained by operators; you select them, you don't edit them, whereas the Pass/Block country rule is yours to edit per project.
## Per-user and per-organization defaults
You can set geobound **defaults for the projects you create** so you don't reconfigure the fence every time:
* **Your profile** carries personal defaults — see [Profile settings](/account/profile).
* An **organization** carries defaults for projects created in it — an org admin sets these in [Organization settings](/account/organizations).
Defaults only seed a *new* project's policy. Enforcement always reads the project's own `geobound_*` values, so changing a default later does not retroactively re-fence existing projects.
## Next steps
How public access works — and how a fence narrows it.
The grants a geobound sits on top of.
For operators: enabling the feature, signal providers, and recovery.
Where geobound controls live in the project form.