AI never touches raw enterprise systems.
One exception, and it's audited.

No MCP tool, no connector, had ever crossed this line before.

AI systems consume reconstructed knowledge
through the Runtime only; they
never touch raw enterprise systems
directly.

The same pipeline every other source goes through. Zero invariant risk.

$ ekos build
Build complete.
  Connectors re-scanned: 7

$ ekos recover
clickhouse-analyzer complete tables=2
Recover complete.
  ClickHouse tables analysed: 2

$ ekos resolve && ekos compile && ekos commit
Commit complete.
  Objects written: 2
  Evidence records: 2

Real columns. Real evidence. Searchable like anything else EKOS has compiled.

Object: ekos_test.orders (Table)
  Properties:
    source_system: "clickhouse"
    engine: "MergeTree"
    columns: [{"data_type":"UInt64","name":"order_id"},
              {"data_type":"String","name":"customer_name"},
              {"data_type":"Decimal(10, 2)","name":"amount"},
              {"data_type":"String","name":"status"},
              {"data_type":"DateTime","name":"created_at"}]
  Evidence:
    [100%] clickhouse:ekos_test.orders — "table ekos_test.orders observed
    via ClickHouse system.tables/system.columns"

This is the same ObjectKind::Table kind file-based SQL DDL already compiles to — not a new Custom("ClickHouseTable") kind. A ClickHouse orders table and a Postgres orders table with overlapping columns become real cross-system identity candidates for free, with zero new exclusion-list code in crates/identity.

Schema-grounded question in. Validated, redacted, audited answer out.

Stage 03 grounds the LLM in the real compiled schema from Stage 1, never a guess. Stage 04 parses the generated SQL with sqlparser's real ClickHouseDialect and hard- rejects anything that isn't exactly one Statement::Query — no INSERT/DROP, no multi-statement batches, a LIMIT injected into the parsed AST if missing. Only SQL that sqlparser itself parsed and re-emitted ever reaches ClickHouse.

Correct SQL, correct answer, live.

$ ekos clickhouse ask --json "how many orders have status shipped?"
{
  "sql": "SELECT COUNT(order_id) FROM ekos_test.orders WHERE status = 'shipped' LIMIT 1000",
  "rows": [{ "COUNT(order_id)": "3" }],
  "audit_event_id": "be4f1866-7fe2-475e-aaf5-32566cbd1d0d"
}

Seed data: 5 orders, status shipped on rows 1, 3, 5 — 3 is the correct answer, verified against the fixture that was actually inserted, not assumed correct because the pipeline didn't error.

The gate guarantees safety, not correctness. This is what that looks like.

$ ekos clickhouse ask "list the 3 highest-amount orders, showing customer_name and amount"
Error: query execution failed: api error 404: Code: 47. DB::Exception:
Unknown expression identifier `name` in scope SELECT name, amount FROM
(... WHERE status = 'completed') ...  (UNKNOWN_IDENTIFIER)

The model invented a status = 'completed' filter — that value never existed in the real data — and referenced name instead of the aliased customer_name. It's still exactly one well-formed SELECT, so the safety gate has nothing to reject; ClickHouse's real schema does the rejecting instead. No row returned, no ledger entry written, no confident wrong answer — a plain error surfaced straight through.

One Event/Evidence pair per successful query. Zero for the failed ones.

SELECT entry_type, count(*)
FROM entries GROUP BY entry_type;

event    | 3
evidence | 6
object   | 3

Off by default. Verified absent and present, over the real protocol.

tools/list -> contains ekos_clickhouse_query: true
tools/call -> {"COUNT(order_id)": "3"}

tools/list -> contains ekos_clickhouse_query: false
tools/call -> isError: true
  "ekos_clickhouse_query is disabled -- set
   [clickhouse].enable-mcp-query = true"

The gate is enforced twice, independently: hidden from tools/list so a well-behaved agent never sees it, and re-checked inside call_tool so a client calling it by name directly — without ever having listed it — is still rejected.