Connect your estate

A connector reads one of your systems into a knowledge base in your own account. The engine reads each source with read-only access, keeps a cursor so each pull reads only what changed, and writes one Markdown document per item into your deployment’s corpus.

The three ways to connect

Way	Where	For
In LightHouse	Setup and admin → Connectors	GitHub, GitLab and Datadog. Approve LightHouse at the provider, or paste a read-only token. LightHouse checks the credential, refuses one with write access, and seals it
From a terminal Coming	The lighthouse CLI	The same approval from a device code, or an existing gh or glab sign-in
In code	A source card in your deployment’s catalogue	Every connector the engine has. Your engineer, or Atlantic’s certified forward-deployed engineers, add the card and point it at a credential in your own secret store

What connecting in LightHouse does today

Connecting in LightHouse verifies the credential’s identity and scopes, tracks its expiry and health, and keeps it sealed. Your deployment does not yet take its credential from LightHouse: the engine reads each source’s credential from your own secret store, set up with the source’s card (In code). Handing a LightHouse connection to your deployment is Coming.

There is no connector-specific one-click stack: a source is a card in your catalogue, and its credential a secret your stack already knows how to pass (Clouds).

Read-only by default

Every connector asks for the narrowest read permission its source offers, and each page lists them exactly. LightHouse refuses a token or approval that carries a write scope. Why: an agent that answers from your repositories has no reason to be able to change them, and a credential that can only read can only leak what it reads.

Where every credential is held

• For your deployment: in your own account. The engine reads each credential from an environment variable that your platform fills from your secret store. On AWS, the stack takes a Secrets Manager or Systems Manager reference for each one (app_secrets on the services, secrets on scheduled jobs), or the engine resolves AAL_SECRET_ARNS itself at start and stops if a reference cannot be read. On your own servers, secrets are files beside the Compose stack.
• For a LightHouse connection: sealed by LightHouse under a key dedicated to your tenant (AES-256-GCM, envelope-encrypted with a key-management data key), stored with its fingerprint, scopes and expiry. It is never shown again. If your tenant’s key is unavailable, LightHouse refuses to store it (503 secret_store_unavailable).

See Where everything lives.

Connectors

Connector	Engine reads it	In LightHouse
GitHub	Yes	Yes
GitLab	Yes	Yes
Datadog	Yes	Yes
Confluence	Yes	Configured in your deployment
Jira	Yes	Configured in your deployment
Google Drive	Yes	Configured in your deployment
Upload (a folder)	Yes	Configured in your deployment
Gmail (one labelled mailbox)	Yes	Configured in your deployment
RSS and Atom feeds	Yes	Configured in your deployment
SharePoint and OneDrive	Coming
Amazon S3	Coming
Salesforce	Coming
ServiceNow	Coming
Slack	Coming
Microsoft Teams	Coming
PostgreSQL	Coming
Snowflake	Coming

A connector LightHouse does not yet offer refuses every connect request with 409 connector_coming. A connector you build yourself registers under the engine’s aal_engine.connectors entry point, so your code stays in your repository.

Check a connection

• In LightHouse: each connector’s card shows its state (healthy, expiring within 14 days, failing, disconnected) and, from your deployment’s telemetry over the last 7 days, the pulls, items written and failures. POST /api/v1/connections/{cid}/health re-checks the credential with the provider.
• In your deployment: each pull’s result is the run’s note, written N, unchanged N, quarantined N, removed N, and a connector record to LightHouse.
• The knowledge base: Agents → Knowledge shows documents by source, the last successful ingest and failures by class.

Requesting a connector

Ask Atlantic: atlanticagenticlabs.com.