> For the complete documentation index, see [llms.txt](https://docs.algenta.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.algenta.ai/trust-and-security/data-boundaries.md).

# Data boundaries

Every outbound network call the engine can make is classified into one of five categories and gated by deployment mode — plus what the SSRF guard blocks unconditionally.

For how to read, tighten, and audit this policy on a running deployment, see [Audit and tighten egress](/deploy-and-operate/privacy-egress.md). This page states the control, not the procedure.

## Every outbound call is classified before it is allowed

The engine does not have a single "outbound network on/off" switch. Every attempted egress is classified into exactly one of five classes, and each class is gated independently:

| Class                | What it is                                                                      | Gated by                                                          |
| -------------------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| `algenta_cloud`      | Calls to Algenta-owned infrastructure                                           | `disable_cloud` + outbound network allowed                        |
| `vendor_telemetry`   | Opt-in usage telemetry                                                          | `disable_telemetry` + `telemetry_mode` + outbound network allowed |
| `customer_connector` | A connector or integration you explicitly configured                            | Your own configuration; not blanket-gated                         |
| `operator_service`   | Infra you pointed the engine at (your own Postgres, Redis, S3-compatible store) | Not blanket-gated — this is traffic you asked for                 |
| `undeclared_public`  | Anything else                                                                   | The outbound-network switch alone                                 |

A destination's class is derived from the destination itself (is it an Algenta-owned host? a known vendor-telemetry host? explicitly configured?) — never from which code path is asking, so a call cannot claim a more permissive class than its actual destination warrants.

## Deployment mode sets the defaults, not the ceiling

`self_hosted` and `air_gapped` deployments default every outbound-network-gated class to off. `air_gapped` additionally refuses to start if telemetry or metering is configured for control-plane sync — that combination is rejected at configuration time, not silently ignored. `saas` and `vpc`/`hybrid_provider` modes carry different defaults appropriate to how Algenta operates them. In every mode, the defaults are configuration, not a hard limit — see [Audit and tighten egress](/deploy-and-operate/privacy-egress.md) for how to change them, and `GET /v1/admin/privacy-report` for what is actually in effect on a running instance right now.

## The SSRF guard blocks a specific set of addresses unconditionally

Independent of egress class or deployment mode, an outbound call is refused outright — no allowlist entry, no configuration, can override this — when its destination resolves to:

* Link-local space (`169.254.0.0/16`), including cloud metadata endpoints (`169.254.169.254`, and the IPv6 forms that smuggle it — an IPv4-mapped address, the NAT64 embedding, and the explicit AWS IPv6 metadata address `fd00:ec2::254`)
* Multicast or unspecified addresses

Private and loopback addresses (an internal `10.x` sidecar, `::1`) are treated differently: they are legitimate when explicitly allowlisted (your own Postgres is exactly this shape), so they stay gated by your configuration rather than blocked unconditionally — the metadata-endpoint case above is the one where even an allowlisted destination must not be reachable through it.

## Air-gapped means air-gapped

An `air_gapped` deployment that is also configured for `control_plane_sync` telemetry or metering refuses to start. This is enforced at configuration validation, not left as a runtime toggle that could be flipped without anyone noticing — the two settings are mutually exclusive by construction.

## Next steps

* [Audit and tighten egress](/deploy-and-operate/privacy-egress.md)
* [Trust overview](/trust-and-security/overview.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.algenta.ai/trust-and-security/data-boundaries.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.