Oracle Database

The engine reads the tables and views you name, in place, from your own database, through a read-only user, into a knowledge base.

Content is read in place, in your deployment, in your own account. LightHouse receives ids, hashes and counts only. The records are not transmitted, and LightHouse does not open the credential.

The way to connect

Way	What you do
Give a read-only database user	Make a user with CREATE SESSION and SELECT on the named tables and views, and nothing else. Paste three lines: the connect string (host:port/service_name), the user and its password

Connect in LightHouse

You need the Client administrator (client_admin) role, signed in as a person, and a deployment whose engine reads this connector (compatibility reference) and keeps credentials in your own store.

1. Go to Setup and admin → Connectors, find Oracle Database (search for it, or filter by its family), and choose Connect.
2. Fill in tables.
3. The connection is Read only: this connector offers no other level.
4. Paste three lines: the connect string, the user, then its password. Your browser seals it to your deployment; LightHouse never sees it.
5. Your deployment keeps it and checks it at the provider. The card shows the result.

Connect in code

- id: oracle-db-knowledge
  purpose: Read Oracle Database into the knowledge base.
  executor: python
  target: aal_engine.ingest.connector:run_card
  overseer: ops-lead@example.com
  budget_usd: 0
  effect: internal
  source:
    kind: oracle-db
    tables:
      - table: SUPPORT.KNOWN_ISSUES
        key: ISSUE_ID
        updated: LAST_UPDATED          # optional: read whole on every pull without it
        title: SUMMARY                 # optional
        columns: [SUMMARY, FLEET, WORKAROUND, STATUS]   # optional: every column otherwise
    label: internal
    credential_secret: <connection id>
    requires:
      reads: [oracle-db:SUPPORT.KNOWN_ISSUES]
      reason: the engineering agents answer from the known-issues register

Privileges

• Read only, always: CREATE SESSION and SELECT on the named objects. Read and write is not offered.
• Only SELECT is ever run, in a read-only transaction. Every name is checked and quoted, and every value is a bind variable.
• The health check: your deployment connects and asks the database for the session’s privileges. They are the card’s scopes, and any privilege beyond reading is flagged: a connection whose user could change the database is marked failing.
• Where it connects: from your deployment, in your network, with python-oracledb in thin mode (the engine’s oracle extra; no Oracle Instant Client).

Where the credential is held

LightHouse never opens this credential. It is sealed in your browser, or by lighthouse-ai connect oracle-db --credential-stdin, to your deployment’s own key, and your deployment keeps it in your own secrets store under lighthouse/connectors/oracle-db/<connection id>. A request that sends it to LightHouse unsealed is refused with 422 sealing_required. LightHouse keeps the connection’s fingerprint, the access level, the scopes the provider states and when it was checked: never the credential, and never what it reads.

See Where every credential is held.

What is indexed

• Rows of the tables and views named, one document per row, with the columns named.
• How often, and what is read each time: on the card’s schedule. With an updated column, each pull reads rows later than the cursor (less a five-minute margin for long transactions), in order. Without one, the table is read whole on every pull and only rows that changed are written.
• Deletions: every six hours the keys are listed and a row that has gone is removed. A table the user can no longer see keeps its rows until it can be listed again.
• Large values: a LOB is read as text up to a cap; binary values are never written.
• Never read: tables and views you do not name.

Check it worked

• The source’s run note in your deployment: written N, unchanged N, quarantined N, removed N.
• Agents → Knowledge: documents from oracle-db.
• Content is read in place, in your deployment. LightHouse receives ids, hashes and counts only; the records are not transmitted.

Removing it

On the card, choose Disconnect. Your deployment deletes the credential from your store. Lock or drop the user, as the database’s administrator (ALTER USER <user> ACCOUNT LOCK). Documents already written stay in the corpus until you delete them.