Technical overview

What Conarium actually does, how it fails, and — just as important — what it does not protect against. Written for the engineer who has to put this in the path between an AI assistant and a real database.

What it is

Conarium is a self-hosted governance layer that sits between an AI assistant (Cursor, Copilot, Claude Code, Windsurf, or any MCP client) and your data. Every query the assistant issues passes through Conarium first. Sensitive values are masked before the model sees them, writes are refused, and every access is written to a tamper-evident, PII-safe audit log. It runs entirely inside your perimeter — the vendor never receives your data.

How it works

AI assistant ──MCP──▶  Conarium  ──▶  your database / docs / APIs
                          │
                          ├─ parse & analyse the SQL
                          ├─ enforce read-only + allow/deny + row caps
                          ├─ mask PII in the result before it returns
                          └─ append a hash-chained audit entry
                          ▼
              masked result ──▶ AI assistant     real values ──▶ you

The assistant reasons on masked tokens it cannot de-anonymize; the operator sees the real values on the way back. Connectors cover Postgres, internal docs, OpenAPI specs, Jira and Slack, exposed to every assistant over MCP.

Guarantees

These are enforced in code, not policy prose:

• Read-only by default. Only SELECT/WITH queries pass. DROP, DELETE, UPDATE, INSERT, ALTER, CREATE, TRUNCATE are blocked — including when smuggled inside comments or stacked queries (SELECT 1; DROP …).
• Fail-closed. If a query cannot be parsed, if a masked column's output cannot be safely redacted, or if a table/connector isn't allowed by policy, the request is denied (a PolicyError is thrown) — never passed through. Uncertainty resolves to refusal, not leakage.
• PII masking before the model. Emails, national IDs, phone numbers and card numbers are redacted in the response stream — plaintext and base64-encoded, so encode-tricks don't slip through. Non-PII text is left intact (no false positives).
• Row caps. A hard per-query limit (default 100) stops silent bulk exfiltration.
• Tamper-evident, PII-safe audit. Every access is appended to a hash-chained JSONL ledger — who, what, when, rows, decision. Alter one entry and the chain breaks on the next read. The audit itself is masked, so it never stores raw PII.
• Self-hosted. Runs on your infrastructure. Your data never crosses your perimeter.

Policy model

Policy is a small JSON document. Nothing is allowed unless you allow it; anything on a deny list is refused first.

{
  "allowTables":   ["public.customers", "public.orders"],
  "denyTables":    ["*.secrets", "*.admin_users"],
  "maskColumns":   ["*.email", "*.phone", "*.tax_id"],
  "maxRows":       100,
  "allowConnectors": ["postgres", "docs"]
}

Threat model

Defends against

• An AI assistant reading raw customer PII / secrets straight out of a production database.
• Write, delete or bulk-exfiltration via AI-generated SQL — including obfuscated or stacked attempts.
• Unaudited AI access — you can prove, after the fact, exactly what the model saw.
• Access to deny-listed tables (secrets, admin, system catalogs).

Out of scope

• A malicious human with direct DB credentials.
• Compromise of the host infrastructure Conarium runs on.
• Your chosen LLM provider's retention policy — self-hosting lets you pick a zero-retention endpoint, but that choice is yours.

Run it yourself

Conarium runs as a single service inside your infrastructure (local, VPC, or air-gapped). It's a standard MCP stdio server — your assistant launches it and speaks MCP over stdio. It needs no inbound port and never phones home.

Get the code

git clone https://github.com/dogrucanemek-alt/conarium.git
cd conarium

With Docker

docker build -t conarium .
docker run --rm -i \
  -v "$PWD/conarium.config.json:/app/conarium.config.json:ro" \
  conarium --config /app/conarium.config.json

With Node (≥18)

npm ci
npm run build          # tsc → dist/
node dist/index.js --config ./conarium.config.json

Point your assistant at it

Register Conarium as an MCP server over stdio in your client (Cursor, Claude Code, Windsurf…):

{
  "mcpServers": {
    "conarium": {
      "command": "node",
      "args": ["/path/to/conarium/dist/index.js", "--config", "/path/to/conarium.config.json"]
    }
  }
}

From then on, every query the assistant issues passes through Conarium first. It sits in the query path, so plan for it as you would any component there. Its default is to fail closed: if it can't make a safe decision, the assistant gets a refusal — never raw data.

Source: github.com/dogrucanemek-alt/conarium — MIT-licensed. Read it, run it, fork it. Questions: e.dogru@conarium.dev.

Status & maturity — honestly

Conarium is early. It is pre-1.0, built and run by a solo founder, with one production deployment so far (a live ERP: 115 real customer records, zero leaked to the model). It has no third-party security certification (SOC 2 / ISO) yet — those are on the roadmap, to be earned as the company matures, not claimed before. If you need a certified, multi-customer, enterprise-hardened vendor today, Conarium isn't there yet, and we'd rather tell you than pretend. What we offer right now is a genuinely self-hosted, inspectable governance layer and a direct line to the person who built it.

Continuity — what if the founder disappears?

A fair concern for a solo-founder tool in your data path, and the answer is the license: Conarium is MIT-licensed. You can read the source, run it, fork it and maintain it yourself — forever, no permission needed. If the project stops tomorrow, you're not left with an orphaned black box; you keep a governance layer you fully control. That's the whole point of self-hosted + open-core: your risk isn't tied to our survival. Need a formal source-escrow arrangement on top of that for procurement? Just ask.

---