# Data sovereignty

> Your content stays in your account and is read in place. Export to Atlantic is opt-in and off by default.

## The rule

**Your content stays in your account and is viewed in place.** Your documents, your index, your prompts, your agents’ answers and the approvals they ask for live where the engine runs: your cloud account, your own servers, or a dedicated account Atlantic runs for you. They are never copied to Atlantic.

**Operational telemetry comes to LightHouse.** Counts, costs and timings: how many calls, which model, how many tokens, what it cost, how long it took, whether it passed. Never content. That is what lets LightHouse show you cost, savings, health and evidence across your whole estate without holding your data.

**Content export is opt-in, and off by default.** If you want LightHouse to keep copies of knowledge records and outputs, you can turn export on under a signed data processing agreement. Until you do, there is nothing to export.

Your account your cloud, or your own servers

- **Agents and orchestrator**run your agents and their approvals
- **Gateway**the only path to a model: caps, kill switch, tool gate, masking
- **Your documents and index**indexed and searched where they are
- **Models**your Bedrock, Vertex AI or Azure OpenAI, or a provider's API
- **Content reader**serves read-only views of your content, on request
- **Handler**collects signed commands; your policy decides
- **Your secrets**credentials, in your own secret store
- **Logs**every content read, recorded in your account

Trust boundary · every connection is opened from your side

↓

**Operational telemetry**Counts, costs and timings, signed by your deployment. Never content.

↕

**Content, viewed in place**A read request signed by Atlantic travels down a connection your reader opened. The answer is shown to the person who asked and is not stored.

↑

**Signed commands**Pause, approve, set a limit: made by a person in LightHouse, signed, and checked by your handler against your own policy.

Atlantic's account LightHouse, in the EU (Ireland)

- **Intake**verifies each signature, refuses anything off the allow-list
- **Store**one database, every tenant walled off by row-level security
- **API, MCP and portal**at your tenant's own host
- **Sign-in**through your identity provider, with a second factor

What runs on each side, and the only three things that cross. Content export to Atlantic is a fourth flow, opt-in and off by default.

## What this gives you

- **One place to answer “where is our data?”** The answer is your account. The [where everything lives](/data-sovereignty/where-everything-lives/) page names each component.
- **Your region, your rules.** The engine runs in the region you choose. Models are called in the geography you allow, and the gateway refuses the rest in code. See [Regions](/data-sovereignty/regions/).
- **Control you can exercise alone.** You can stop LightHouse reading your content by stopping one process in your account, or removing one public key. Neither needs Atlantic.
- **A record of every look.** Every time anyone, including Atlantic staff, views your content through LightHouse, your account logs it and LightHouse’s audit log shows it. See [Who can see what](/data-sovereignty/access/).
- **A clean exit.** Export everything LightHouse holds for you at any time, as files with a checksum manifest. See [Leaving](/data-sovereignty/leaving/).

## How “read in place” works

When a person with the `content_viewer` role opens a knowledge record, an output or an approval in LightHouse, the request goes down a connection that your content reader opened from your side. Your reader checks that Atlantic signed the request for your deployment in the last five minutes and has not used it before, reads the item from your own store, and answers. LightHouse shows the answer to that person and does not store it.

Prompts are readable this way only if you have turned prompt retention on in your deployment. Otherwise there are none to read.

The full mechanism, with its signatures and how to verify each step, is on [Architecture and trust boundary](/security/architecture/#content-viewed-in-place).

## How telemetry stays content-free

Every telemetry record type has a fixed list of attributes, and every attribute a fixed kind: a count, a number, an identifier from a fixed vocabulary, a time. Free text is not one of the kinds, with one exception you control: an agent’s published purpose, sent only if your pack chooses to publish it. The engine drops anything off the list before it sends, and LightHouse refuses any record carrying it. A person appears only as a keyed hash computed in your account.

Even the router’s explanation of a decision, which is a table, is limited to model IDs, fixed reason codes, numbers and booleans, and is checked again on arrival. See [the telemetry contract](/concepts/telemetry-contract/).

## Content export

Export exists for clients who want LightHouse to hold a copy, for example for a longer retention than their own systems keep.

- It is **off** unless your tenant’s record turns it on, which needs a signed data processing agreement.
- When on, your content reader pushes knowledge records and outputs to LightHouse. Personal data your policy names is masked by the gateway first.
- Exported content is encrypted under a key held for your tenant alone, and kept for the retention you set (30 days by default).
- `GET /api/v1/me` reports `tier_c` for your tenant, so you can confirm whether it is on.

See [Legal](/data-sovereignty/legal/) for the agreements behind it.

Source: https://docs.atlanticagenticlabs.com/data-sovereignty/