# Architecture and trust boundary

> What runs in your account, what runs in Atlantic's, and what crosses between them.

LightHouse is split in two on purpose. The part that touches your content runs in your account. The part Atlantic runs sees only how that work went.

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 runs in your account

The Atlantic Agentic Engine, deployed by your own pipeline from a stack you review. On AWS, Azure or Google Cloud it runs in your account or subscription; on premises it runs under Docker on your machines. With [Atlantic-hosted](/clouds/atlantic-hosted/), the same engine runs in a dedicated account Atlantic manages for you.

| Component               | What it does                                                                                                                                                                      |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Agents and orchestrator | Run your agents, their steps and their approval points                                                                                                                            |
| Gateway                 | The only path from an agent to a model. Checks the model against your allow list, enforces caps and the kill switch, masks personal data your policy names, and records each call |
| Index and documents     | Your connectors read your sources; the index is built and searched where it lives                                                                                                 |
| Models                  | Called by the gateway in your cloud (Amazon Bedrock, Vertex AI, Azure OpenAI) or through a provider’s API with your key                                                           |
| Content reader          | Answers read-only requests for your content, one at a time, each signed by Atlantic                                                                                               |
| Handler                 | Collects signed commands from LightHouse and applies those your own policy permits                                                                                                |
| Secret store            | Your connector credentials and your deployment’s signing key                                                                                                                      |

Nothing here listens for a connection from Atlantic. The reader and the handler each open one outbound connection, so the only network path the engine needs to LightHouse is outbound HTTPS to one Atlantic hostname, given to you at onboarding.

## What runs in Atlantic’s account

LightHouse: the intake that receives telemetry, the database it is stored in, the API, the MCP server and the portal. It runs on AWS in the EU (Ireland, `eu-west-1`), behind Cloudflare.

Each tenant has its own host, `https://<tenant id>.atlanticagenticlabs.com`. The tenant ID is a random label generated at onboarding. It never names you, because hostnames are public.

## What crosses, and in which direction

Three flows, each opened from your side.

### Operational telemetry, out

Your deployment posts records to LightHouse: one per model call, run, step, search, evaluation, cap, health check and so on. Every record type has a fixed list of attributes. The engine drops anything not on the list before sending, and LightHouse refuses any record that carries one.

What a model call record carries: the agent, the model, token counts, cost, latency and outcome. What it never carries: the prompt, the answer, a document, a passage or a person’s name. A person appears only as a keyed hash computed in your account.

See [the telemetry contract](/concepts/telemetry-contract/) for every record type.

### Content, viewed in place

When a person with the `content_viewer` role opens content in LightHouse (a knowledge record, an agent’s output, an approval), LightHouse sends a read request down the connection your content reader opened. The request is signed with Atlantic’s reader key. Your reader refuses any request that key did not sign for your deployment, that is more than five minutes old, or that it has seen before.

The answer is shown to the person who asked. It is not stored in LightHouse. Your reader logs every read in your account: who asked, which key signed, the request ID, what and when.

You can cut this flow off without Atlantic: stop the reader, or remove Atlantic’s public key from it.

### Signed commands, in

A person with the `handler` role can pause an agent, decide an approval or set a limit in LightHouse. Each command is signed with Atlantic’s command key and collected by your handler over its own outbound connection. Your handler applies it only if your deployment’s own policy permits that command type. See [Approvals](/concepts/approvals/).

### Content export, off by default

A fourth flow exists only if you turn it on: export of knowledge records and outputs into LightHouse, encrypted under a key held for your tenant alone. It needs a signed data processing agreement and is off unless your tenant’s record says otherwise. See [Data sovereignty](/data-sovereignty/).

## How to check the boundary yourself

- **Egress.** Restrict your deployment’s outbound traffic to your model endpoints and the one Atlantic hostname. The engine keeps working; nothing else is needed.
- **What arrives.** `GET /api/v1/runs`, `GET /api/v1/usage` and every other read return counts, timings, identifiers and costs. Search the responses for any text from your documents: there is none to find.
- **Who read your content.** Your reader’s log, in your account, lists every content read. In LightHouse, `GET /api/v1/audit` lists them too, as `content_read`.
- **Cutting it off.** Stop the content reader. LightHouse’s content pages then say content cannot be read in place right now (`503 tier_b_unavailable`), and nothing else changes.

**curl**

```bash
# What LightHouse knows about your tenant and your deployments
curl "https://$AAL_TENANT.atlanticagenticlabs.com/api/v1/me" \
  -H "Authorization: Bearer $AAL_KEY" \
  -H "CF-Access-Client-Id: $CF_ACCESS_CLIENT_ID" \
  -H "CF-Access-Client-Secret: $CF_ACCESS_CLIENT_SECRET"
```

**Python**

```python
import os

import httpx

headers = {
    "Authorization": f"Bearer {os.environ['AAL_KEY']}",
    "CF-Access-Client-Id": os.environ["CF_ACCESS_CLIENT_ID"],
    "CF-Access-Client-Secret": os.environ["CF_ACCESS_CLIENT_SECRET"],
}
me = httpx.get(f"https://{os.environ['AAL_TENANT']}.atlanticagenticlabs.com/api/v1/me", headers=headers)
me.raise_for_status()
print(me.json()["deployments"])
```

**TypeScript**

```ts
const res = await fetch(`https://${process.env.AAL_TENANT}.atlanticagenticlabs.com/api/v1/me`, {
  headers: {
    Authorization: `Bearer ${process.env.AAL_KEY}`,
    "CF-Access-Client-Id": process.env.CF_ACCESS_CLIENT_ID!,
    "CF-Access-Client-Secret": process.env.CF_ACCESS_CLIENT_SECRET!,
  },
});
console.log((await res.json()).deployments);
```

`/api/v1/me` also reports `tier_b` (content in place) and `tier_c` (content export) for your tenant, so you can confirm export is off. See the [API reference](/api/reference/people-and-preferences/#me).

Source: https://docs.atlanticagenticlabs.com/security/architecture/