Architecture and trust boundary

View as Markdown

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 orchestratorrun your agents and their approvals
Gatewaythe only path to a model: caps, kill switch, tool gate, masking
Your documents and indexindexed and searched where they are
Modelsyour Bedrock, Vertex AI or Azure OpenAI, or a provider's API
Content readerserves read-only views of your content, on request
Handlercollects signed commands; your policy decides
Your secretscredentials, in your own secret store
Logsevery content read, recorded in your account

Operational telemetryCounts, costs and timings, signed by your deployment. Never content.

Content, viewed in placeA 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 commandsPause, 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)

Intakeverifies each signature, refuses anything off the allow-list
Storeone database, every tenant walled off by row-level security
API, MCP and portalat your tenant's own host
Sign-inthrough 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, 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 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.

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.

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.

# 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"

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"])

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.