Security

This section is written for the person who has to sign off on LightHouse: a security architect, a reviewer, or the engineer who will be asked “how do you know?”.

Each control is described the same way:

• What it is. One or two sentences, no adjectives.
• Where it is enforced. The component that refuses, and whether it sits in your account or in Atlantic’s.
• How to verify it. A request you can send, a header you can inspect, or a record you can read in your own audit log.

Anything not built yet is marked Coming, with no date.

The design in one paragraph

The engine runs in your account and holds your content. LightHouse runs in Atlantic’s account and holds operational telemetry: counts, costs and timings, never content. When a person in LightHouse needs to see content, it is read in place from your account and shown to them, not copied. Every connection between the two is opened from your side, and every message across it is signed. The architecture page draws this boundary.

The controls at a glance

Control	Enforced in	Verify it with
Sign-in through your identity provider, MFA required	The edge and the LightHouse service	GET /api/v1/me shows how your second factor was proved
Machine keys: read only, one tenant, 365 days at most	LightHouse service	A key at another tenant’s host answers 401
Tenant isolation by row-level security	The database	Every query runs under your tenant’s scope; nothing names a tenant in a parameter
Writes audited	LightHouse service	GET /api/v1/audit
A key may never pay, raise a limit or approve	LightHouse service and your handler	Those routes answer 403 person_required to a key
MCP is read only	LightHouse service	No tool approves, pays or changes a limit
Retrieved text is evidence, never instruction	The engine, in your account	The tool gate refuses what the agent’s card does not permit
Content security policy with a per-request nonce	The portal	Inspect Content-Security-Policy on any page
Spending caps and kill switches in code	The gateway, in your account	A refused call is a model_call with outcome: refused
The Cedar tool gate	The engine, in your account	The tool_denials_total metric in your account, by reason
No long-lived cloud keys	Your cloud’s identity service	Read the roles the stack creates
Signed telemetry	Your deployment signs; intake verifies	An unsigned post answers 401 unsigned
Scanning on every commit and pipeline	Atlantic’s repositories and CI	Ask for the latest reports under NDA

The security controls summary puts the same rows on one page for a questionnaire.

Where to start

Architecture and trust boundaryWhat runs where, and the three things that cross.

API securitySign-in, roles, keys, isolation, limits and audit.

Engine and gatewayControls in code the model cannot reach.

Verify it yourselfTests you can run from outside, today.

Data handling has its own section: Data sovereignty.