# Connect your estate > Every connector, the three ways to connect it, the read-only scopes it asks for, and what it indexes. A connector reads one of your systems into a [knowledge base](/concepts/knowledge-bases/) 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](/build/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](/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](/data-sovereignty/where-everything-lives/). ## Connectors | Connector | Engine reads it | In LightHouse | | ----------------------------------------------- | --------------- | ----------------------------- | | [GitHub](/connect/github/) | Yes | Yes | | [GitLab](/connect/gitlab/) | Yes | Yes | | [Datadog](/connect/datadog/) | Yes | Yes | | [Confluence](/connect/confluence/) | Yes | Configured in your deployment | | [Jira](/connect/jira/) | Yes | Configured in your deployment | | [Google Drive](/connect/google-drive/) | Yes | Configured in your deployment | | [Upload (a folder)](/connect/upload/) | 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](/connect/sharepoint/) | \[Coming] | | | [Amazon S3](/connect/s3/) | \[Coming] | | | [Salesforce](/connect/salesforce/) | \[Coming] | | | [ServiceNow](/connect/servicenow/) | \[Coming] | | | [Slack](/connect/slack/) | \[Coming] | | | [Microsoft Teams](/connect/teams/) | \[Coming] | | | [PostgreSQL](/connect/postgres/) | \[Coming] | | | [Snowflake](/connect/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](https://atlanticagenticlabs.com/#contact). Source: https://docs.atlanticagenticlabs.com/connect/