Skip to main content
Glama
deenkoruzh
dogrucanemek-alt

Conarium

by dogrucanemek-alt
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

网站位于 conarium.dev；此仓库是产品本身。

在阅读其余内容之前先检查

以下内容无需信任。有一条实时收据链；您可以在自己的机器上使用其公钥进行验证，无需账户，也无需您的任何数据：

npm i @conarium-ai/core
curl -fsS https://demo.conarium.dev/proof/chain.jsonl   -o chain.jsonl
curl -fsS https://demo.conarium.dev/proof/key.pem       -o key.pem
curl -fsS https://demo.conarium.dev/proof/key.pem.keyid -o key.pem.keyid
npx conarium-verify chain.jsonl --pubkey key.pem
note: tail truncation is not visible — this run did not see receipts deleted from the
end of the file. Pin with --expect-count, --expect-last-hash, or --anchor-check.
ok: 3 receipt(s) verified (3 with undeclared model, 3 with undeclared client)

退出代码 0。这三张收据分别是：一次普通读取、一次在模型看到之前掩蔽了五个电子邮件地址和一个卡号的读取，以及一次拒绝。更改任何字段，重新计算的哈希将与存储的哈希不匹配——退出代码 10。改为更改签名——退出代码 13。

验证器是一个单一文件，不导入它所检查的包中的任何内容，因此被入侵的 Conarium 无法说服它通过结果。请注意，它会在自己的输出第一行、好消息之前，主动说明它没有检查什么。

Related MCP server: @lucairn/mcp-server

限制

此仓库尚未完成的内容在 LIMITATIONS.md（Türkçe）中。带日期的比较页面是 conarium.dev/compare.html——那是唯一副本；此仓库不保留第二份。

标准

draft-dogru-scitt-disclosure-evidence 是个体提交。未被 IETF 工作组采纳，也不具有正式地位——互联网草案是带日期的公开记录，而非标准。发布它是为了让收据格式可以在没有我们的情况下实现。源文件位于 standards/。

👁️ 问题

将 Cursor 或 Copilot 指向生产数据库，它会直接读取原始数据流——社会安全号码、信用卡、工资和实时密钥。一个恶意提示就能暴露您最敏感的表。安全团队绝不能允许这种情况。

🛡️ 解决方案：Conarium

Conarium 充当高性能 MCP（模型上下文协议）代理。它直接位于 AI 助手和您的数据库之间，在毫秒内评估策略，以强制执行行数限制并在传输中掩蔽 PII（个人身份信息）。

AI 获得编写代码所需的上下文；您的策略保护的值在到达之前被掩蔽。掩蔽隐藏值——它不会使其不可学习，并且在请求语言允许对受保护列进行谓词的情况下，允许的查询仍然可以回答关于该列的问题。protectedColumns 是更窄的答案，限制在 LIMITATIONS.md 中说明，而不是留给您去发现。

主要特性

  • 内联 PII 掩蔽： 电子邮件、ID、卡号和秘密在响应流中被编辑（[MASKED_PII] / [MASKED_SECRET]），在模型看到任何字符之前。

  • 允许/拒绝列表： 白名单 AI 可以访问的内容。您的 secrets 和 financials 表保持不可见。

  • 行数上限： 每次查询的硬性限制。防止数百万行的静默外泄。

  • 防篡改审计账本： 每次通过 Conarium 的访问都被记录（谁、什么、何时、行数、决策）。哈希链式，使更改和中间删除可检测——并非不可能：磁盘上的文件仍可被删除或截断，捕获截断需要来自文件外部的固定点（见覆盖与对账）。PII 安全：日志中不写入原始 PII。

  • 可验证收据： Ed25519 签名、可独立验证的收据——见下文。

  • 个人掩蔽配置文件： 对 AI 代理的掩蔽与对数据控制者的掩蔽不同。命名配置文件为一位已识别的人放宽掩蔽，收据记录应用了哪个配置文件——见下文。

  • 覆盖与对账： 对收据链的签名覆盖声明（conarium-coverage），以及针对数据库自身查询计数器的双向对账（conarium-reconcile）——没有收据覆盖的数据库记录活动会被暴露，而不是保持不可见。

  • 100% 自托管： 完全在您的基础设施上运行。我们提供的任何内容都不会将您的数据传输到任何地方：原始受保护值留在您的边界内，到达您的 AI 客户端的是策略批准的披露——其确切字节由收据记录（disclosure.hash）。说您的数据从未离开是完全错误的说法：向助手发布受治理的披露正是其工作。网关只发出一个不是您发出的出站请求：启动时它向公共 npm 注册表询问是否有新版本，如果有则向 stderr 打印一行。它不会发送关于您的任何信息——没有标识符、没有配置、没有计数——而一个数周无人查看的远程网关正是它存在的原因。使用 CONARIUM_NO_UPDATE_CHECK=1 禁用它，或使用 CONARIUM_NPM_REGISTRY 将其指向您的内部镜像。它有 2 秒超时，永远不会阻塞或导致启动失败。我们列出它是因为一个进行未披露出站连接的治理产品已经失去了论点。

  • MCP 原生： 与 Cursor、GitHub Copilot、Claude Code 和 Codex 开箱即用。

可验证收据

Conarium 可以发出可移植的收据（Art. 12 / 19 形状），第三方可以使用单个文件离线验证——无需安装 Conarium。

官方声明（不要扩大）： Conarium 收据证明文件中仍然存在的记录在创建后未被更改、重新排序或回溯日期，并且没有从链的中间被移除（prevHash / seq）。它不证明它们在创建时是正确的。它也无法单独证明记录没有被从末尾丢弃：较短的剩余链仍然内部一致。捕获尾部截断需要来自文件外部的固定点——--expect-count、--expect-last-hash、OpenTimestamps 锚点或 conarium-reconcile 针对数据库自身计数器。

(TR) Conarium Makbuzu, dosyada hâlâ duran kayıtların oluşturulduktan sonra değiştirilmediğini, ortadan silinmediğini, yeniden sıralanmadığını ve geriye dönük tarihlenmediğini kanıtlar. Oluşturma anında doğru olduğunu kanıtlamaz. Sondan kesmeyi tek başına göremez: kalan zincir tutarlıdır, yalnızca kısadır. (/TR)

# Generate an Ed25519 keypair (private PEM + .pub.pem + .keyid sidecars).
# The .keyid sidecars are not optional: without them the verifier answers 13
# for every receipt, which reads like tampering and is not.
npx conarium-init

export CONARIUM_AUDIT_SIGNING_KEY=./audit-ed25519.pem

# init writes keys and config, not receipts: your own audit file does not exist
# until the gateway has served a query. The three commands below therefore run
# against the demo chain downloaded above, so they work as written — swap in
# your own sink (conarium.config.json → audit.sink) once it has records.

# Verify a receipt chain (exit 0 = the records *in the file* are intact)
npx conarium-verify chain.jsonl --pubkey key.pem

# Pin length / last hash if you need to catch records dropped from the end
npx conarium-verify chain.jsonl --pubkey key.pem --expect-count 3

# Check the OpenTimestamps sidecar. The demo chain ships without one, so this
# answers 14, deliberately not 0: an absent anchor is not a verified anchor.
# A sidecar that exists but is not yet confirmed → exit 0 with a warning.
npx conarium-verify chain.jsonl --pubkey key.pem --anchor-check

第二个验证器，仅使用 Go 和标准库，位于 verifiers/go。go build -o conarium-verify . 然后使用与 conarium-verify 相同的参数；test-vectors/ 是契约。

可选锚定：CONARIUM_ANCHOR_SINK=opentimestamps。稍后使用 npx conarium-anchor-upgrade ./audit.jsonl.anchors.jsonl 升级待处理的证明。客户端在树内（Node crypto + 日历 HTTPS）。它不安装 javascript-opentimestamps。参见 LIMITATIONS.md。

个人掩蔽配置文件

对 AI 代理正确的掩蔽对数据所有者是错误的。所有者询问“哪个客户欠款最多”需要姓名；助手总结收入则不需要。用全局开关回答会禁用产品唯一的真正保证，因此掩蔽按个人解析：

{
  "policy": {
    "allowTables": ["zion.customers", "zion.orders"],
    "maskColumns": ["*.customer_name", "*.email", "*.phone"],  // default: everyone
    "maxRows": 100,

    "profiles": {
      // The controller sees customer names; email and phone stay masked.
      "controller-full": { "maskColumns": ["*.email", "*.phone"], "maxRows": 1000 }
    },
    "actorProfiles": { "emekcan": "controller-full" }
  }
}

刻意狭窄，因为这是唯一可能放松保护的功能：

  • 配置文件可以覆盖 maskColumns、maxRows 和 maskLabelledNames——仅此而已。 表、工具和连接器权限保持全局；配置文件永远不能扩大可访问范围，只能扩大其中的可读性。protectedColumns 不可叠加：可以丢弃它的配置文件将成为个人后门。

  • 仅限每用户令牌。 使用共享令牌认证的参与者永远不会收到配置文件。“谁持有此字符串谁就能看到未掩蔽的 PII”正是本产品要防止的失败。

  • 其他情况均失败关闭： 无参与者、未列出的参与者或不存在的配置文件名称都回退到基础策略，绝不会回退到更宽的策略。

  • 内容扫描器仍然运行。 电子邮件/国家 ID/电话/卡/IBAN/秘密检测器不可覆盖，因此无论应用哪个配置文件，这些在自由文本中都会被掩蔽。IBAN 仅在 ISO 7064 mod-97-10 成立时接受。护照 MRZ（TD3，7-3-1 校验位）默认开启，同样不能由配置文件关闭——只有基础策略上的 policy.detectors.mrz: false 可以退出。IP 地址在 policy.detectors.ip: true 之前关闭。名称掩蔽是配置文件可以关闭的唯一检测器（maskLabelledNames: false），因为控制者阅读自己的客户列表正是此功能存在的场景。

  • 收据说明应用了哪个配置文件——policy.id 变为 conarium.policy/<profile>，在签名哈希内。在放宽配置文件下进行的访问不能后来被呈现为完全掩蔽。这正是审计故事保持诚实的原因：重点从来不是“没有人看到 PII”，而是“每次访问都受治理，证据说明在哪些规则下”。

自由文本中的名称

其他每个标识符都有形状。电子邮件有 @，国家 ID 有校验和，卡有长度——正则表达式决定，决策可重现。名称没有形状，因此 maskColumns 是唯一能捕获它的东西，而输入到自由文本 note 中的名称会原样到达模型。

两个确定性传递关闭了可以诚实关闭的那部分差距：

传递

触发条件

示例

携带

该值此策略已在某列中掩蔽

customer_name 被掩蔽，因此 note: "Ayşe Demir called" 也被掩蔽——包括跨行

标记

文本本身标记：标题或字段标签

Sn. Ahmet Yılmaz、Yetkili: Ayşe Demir、customer: John Smith

它刻意不做的事：正文中出现的裸名称不会被检测。"Ahmet 昨天打来电话"会直接通过。要捕捉这类情况需要 NER——一个模型、一个词典和一个置信度分数——而这个网关做出的每一个决定都旨在仅凭规则即可复现，由不信任我们的人也能复现。概率性脱敏器也会是概率性的收据。确实运行 NER 的工具（例如基于 Presidio 的工具）覆盖更多实体类型；它们以置信度阈值为代价换取这一点。两种立场都不占优势——这里明确说明，是为了让审计员知道自己拿到的是哪一种。

**内容扫描器仍然捕捉不到的——是设计使然，而非遗漏：**街道地址和裸名称。地址检测器无法在没有地名词典的情况下区分"Atatürk Caddesi No:15"和"Atatürk Barajı"。名称检测器无法区分 Deniz / Güneş / Umut 与普通单词。两者都需要词典或模型；而此网关的决定是确定性的。通过 maskColumns（列名）和 conarium-suggest-policy（基于名称的猜测，不会写入你的配置）来弥补这些缺口。

IP 地址在你开启时才会被捕捉（policy.detectors.ip: true）。它们默认关闭：服务器 IP 不总是个人数据，而一个无法禁用的脱敏会破坏安全运营中心的工作。1.2.3.4 在结构上是合法的 IPv4 地址；当检测器开启时它会被脱敏，即使你本意是版本号。日期（13.08.2026）和金额（1.250,00）不是 IPv4。

自由文本中的护照号码不会被捕捉。**MRZ 会被捕捉：**两行 TD3 × 44 个字符，第 1 位为 P，7-3-1 校验位。校验和不匹配就不是 MRZ，会被放过。TD1/TD2 未实现。

HTML &#64; / &#x40;、JSON \u0040 和 %40 在位于电子邮件形态的令牌内部时会被脱敏。单独的 5&#64; store 或 C:\path\u0040abc 会被放过。只做一次解码；&amp;#64; 不会被追查。

同一行上分布在两个名称相似的字段中的 TCKN（tckn_1 / tckn_2），当拼接后校验和通过时会被脱敏。不相关的列不会被合并。

零宽字符、全角数字 / ＠ 以及 Unicode 破折号会在检测器运行之前被剥离或映射为 ASCII——这一遍不是通用编码解码器；字段内包装过的 base64/hex 令牌只有在解码后命中现有检测器时才会被脱敏。

扫描长度。 单个文本字段超过 policy.scanCharCap（默认 16 384；环境变量 CONARIUM_SCAN_CHAR_CAP 可覆盖）时，整个字段会被替换为 [MASKED_PII]，即使其中不包含任何标识符。扫描器不会被跳过：跳过意味着一条长备注、JSON 块或日志行就成了绕过脱敏的途径。这是一个可用性设置。提高它会以二次方速度增加扫描成本——一个 40 KB 的字母数字字段在无界邮箱正则被加上边界之前耗时约 1 秒。maskedCount 记录已做出决定。

结转忽略少于三个字符的值（两个字符的值处处匹配，会把输出撕碎），并在 Unicode 词边界上匹配，因此 Ali 在 Ali onayladı 中会被脱敏，但在 Kalite 内部不会。

覆盖与对账（绕过检测）

收据证明什么经过了网关。对账则询问数据库它看到了什么，并进行比较：

两个命令都不会凭空发明输入，conarium-init 也不会创建它们，因此在你自己生成它们之前，两者都回答 20（输入缺失）：declaration.json 是你自己的期间与范围声明（docs/RECEIPT-SPEC.md 列出了字段名），两份快照来自 scripts/pg-snapshot.sql。

# One-sided: signed coverage declaration over a period + declared scope
npx conarium-coverage ./declaration.json --pubkey ./audit-ed25519.pub.pem --receipts ./receipts.jsonl

# Two-sided: reconcile the DB's own per-role query counters against receipts.
# Snapshots come from pg_stat_statements (scripts/pg-snapshot.sql), taken at
# window start and window end with a dedicated DB role per gateway instance.
npx conarium-reconcile --before before.json --after after.json --receipts ./receipts.jsonl
# exit 0  = every DB query pattern in the window is attributable to a receipt for
#           the same table (object attribution, not per-statement coverage —
#           see LIMITATIONS.md)
# exit 40 = the DB recorded activity no receipt covers — the gateway may have
#           been bypassed, or the receipt sink failed

措辞是刻意的：缺失被报告为**"访问未记录"** / "未出具收据"，绝不说是"未发生访问"——缺失的记录本质上就是模糊的，而假装不是这样的工具就是在对审计员撒谎。

在我们自己的生产 ERP 上运行的那一天，包括我们对自己执行的一次真实绕过且工具捕捉到了它：docs/dogfood/2026-08-06-reconcile.md。

完整模式、退出码和已知缺口：docs/RECEIPT-SPEC.md。

会签（你无法为自己完成的部分）

收据证明什么经过了网关。对账证明没有东西绕过它。两者都是你的，自托管，并由你自己的密钥签名——而这恰恰是审计员打折扣的地方：你保留了记录，你签了名，你存储了它。会签通过在同一个链头上加上第二方来回应这一点。

该服务包含在此包中，因此你可以运行自己的并签署自己的链头——对第二个内部保管人有用，但针对上述质疑毫无意义。它之所以有价值，是因为签名者不是你。

# Run the endpoint. It refuses to start without a signing key or a token file:
# with neither present the three lines below exit 2 and name what is missing,
# which is the intended answer, not a failed install. Generating both is in
# deploy/anchor-service/.
CONARIUM_ANCHOR_TOKENS=./anchor.tokens.json \
CONARIUM_ANCHOR_SIGNING_KEY=./anchor.pem \
CONARIUM_ANCHOR_BASE_URL=https://anchor.example.com \
npx conarium-anchor-service

# Verify a countersignature you were given — offline, no network, no package.
# record.json is what the endpoint returned to you; without it, exit 20.
npx conarium-countersign-verify ./record.json --pubkey ./anchor.pub.pem
# exit 0  = signature valid (and inclusion valid if a proof or --log-url was given)
# exit 13 = signature invalid / unknown keyId
# exit 14 = inclusion proof present and false
# exit 15 = the log could NOT be checked — deliberately not the same as 14

日志是哈希链：条目只追加，从不重写，OTS 时间戳覆盖链头而非每条提交。会签证明了什么——同样重要的是，它不证明什么——在 docs/COUNTERSIGN.md 中写明了，连同签名密钥泄露会付出什么代价。

Pro 是托管式会签——由你之外的某人签署链头。每月 20 美元或每年 200 美元——节省 40 美元。 一个期间，不是订阅。 它不会自动续期——期间结束时访问即结束，你可以再次购买。14 天无理由退款；之后不提供部分退款。适用地区加收增值税。结账尚未开放：conarium.dev/buy 在支付路径上线前重定向到候补名单表单，因此这些条款是公布的价格，而非你今天就能付款购买的东西。上面的二进制文件是你自己运行的；Pro 是第二个签名者。自 0.2.16 起随包发布；VERAX 运营的端点尚未对客户开放。企业版仍在候补名单上：计划对账、覆盖警报和签名期间报告在合同中，尚未发布。

自行实现该格式

收据旨在比此实现更长寿，因此它附带一致性测试向量——十二个冻结用例加上一个机器可读清单，位于 test-vectors/：

npm run test:vectors     # our verifier against the frozen cases

将你自己的验证器指向每个 receipts.jsonl，传入 manifest.json 中列出的参数，并比较退出码。expected-hashes.json 给出规范的 JCS → SHA-256 哈希，这样你可以在不需要我们的私钥的情况下检查你的规范化——该私钥刻意不发布。

这些向量在首次运行时在此仓库中发现了两个问题：一个模式检查将结构无效的收据报告为被篡改，以及我们关于未签名收据的一个错误假设。两者现在已冻结为用例 007 和 008。

锚定你的链（可选）

conarium-stamp 将文件锚定到 OpenTimestamps 日历，conarium-anchor-upgrade 在比特币区块高度落地后填入它。这两个就是大多数部署所需的全部。

如果你更愿意将锚定暴露为一个小型服务——用于多个网关，或给审计员一个稳定的 URL——bin/conarium-anchor-service.mjs 就是这样一个服务：它提交哈希、保留证明、在永久路径上提供原始 .ots 文件，并定时升级待处理的锚点。

它是你运行的代码，不是我们运营的服务——没有托管实例可供注册。它提供原始证明，正是为了让第三方可以用参考 OpenTimestamps 客户端验证并完全忽略该服务。一个你必须信任的锚定端点会破坏锚定的目的。

签名是故障关闭的：设置 CONARIUM_AUDIT_SIGNING_KEY 和/或 CONARIUM_AUDIT_HMAC_KEY，或为一次性设置显式设置 CONARIUM_AUDIT_UNSIGNED=1。密钥轮换：将先前的公钥 PEM 保留在 CONARIUM_AUDIT_TRUST_PUBKEYS 中（以 , / ; 分隔）。在第一条签名审计行之后，之后的每一行都必须携带 sig。

在类似项目中的定位

Conarium 不是第一个为 AI 活动生成签名、可验证收据的项目。Acta、Emilia Protocol、AuthProof、Agent Receipts 和 Invariant SVR 都以某种形式做这件事，有些在标准化方面领先于我们——Acta 和 Emilia 都有 IETF Internet-Draft。相关研究：Aegon（arXiv 2604.06693）、Decentralised Trust Layers（ACM Web Conf 2026）以及用于签名同意记录的 ISO/IEC TS 27560:2023。

那些收据证明的是代理做了什么。Conarium 收据证明的是模型被阻止看到什么——因为对数据进行脱敏的组件与签署记录的组件是同一个。执行与证据在这里是一个部分，而不是两个必须对账的系统。

我们要捍卫的是：Conarium 是我们所知的唯一一个将以下三者结合的实现：(1) 内联执行（策略 + 脱敏）、(2) 该执行的可移植、离线可验证收据，以及 (3) 覆盖对账——将数据库自身的查询计数器与收据链进行核对，使绕过网关的访问浮出水面而不是保持不可见。只签名收据而不执行很常见；执行但没有可移植收据也很常见；将两侧与数据源自身的记账进行对账，是我们没有在其他地方找到的部分。在真实运营公司的实时 ERP 上端到端测量——121,374 条记录，121,366 个身份被脱敏，485,496 个字段被脱敏，零泄露给模型（治理报告 001）。

那个数字是什么，不是什么。 它来自对我们自己公司 ERP 的一次批处理运行，支撑它的是一个 123 行的哈希链审计文件，其算术你可以自己重新加一遍，其链在 17 天后被重新验证。不支撑它的是收据链：那次运行产生的是审计条目，不是签名的可移植收据，其行为主体是批处理服务身份，不是个人。所以如果你问"给我看那 485,496 个字段的收据"，诚实的回答是它们不存在——收据链是一个独立的、小得多的度量。规模和离线可验证性在这里是两个不同的主张，我们宁愿自己划清这条线，也不愿让你发现它。该机制无需信任我们即可验证；这个具体数字是我们自己的测量，治理报告 001 列出了其局限。

那个主张是刻意设限的，docs/PRIOR-ART.md 是其背后的证据：2026 年 8 月 6 日检查的十个项目、每个项目拥有什么、最接近的学术先例（Sello / Notarized Agents，它比我们更好地命名了这个缺口），以及九件我们无法验证的事情。如果你知道有实现将三者结合的实现，请开一个 issue，它将被更正。

🏗️ 架构（三位一体）

Conarium 基于严格的三方架构运行，在三大支柱之间平衡权力：

graph LR
    A([AI Assistant\nCursor / Copilot]) -- "MCP Query" --> B{The Gateway\nConarium Proxy};
    B -- "Intercept & Parse" --> C[The Engine\nGovernance & Regex];
    C -- "Execute Query" --> D[(Your Database\nPostgres / SQL Server / Oracle)];
    D -- "Raw Data" --> C;
    C -- "Mask & Cap" --> B;
    B -- "Sanitized Data" --> A;
    C -. "Write Log" .-> E[The Ledger\nAudit DB];
    
    style A fill:#05070f,stroke:#5a8cff,stroke-width:2px,color:#fff
    style B fill:#05070f,stroke:#ff6f80,stroke-width:2px,color:#fff
    style C fill:#05070f,stroke:#6fe0e0,stroke-width:2px,color:#fff
    style D fill:#05070f,stroke:#f2d79a,stroke-width:2px,color:#fff
    style E fill:#05070f,stroke:#838dad,stroke-width:2px,color:#fff

  1. 网关： 一个能与 LLM 助手流畅对话的代理。

  2. 引擎： 在毫秒内评估 JSON 策略、正则扫描和行数上限。

  3. 账本： 一个防篡改的审计日志，记录它调解的每一次查询和决定。

🚀 快速开始

# 1. Install
npm i @conarium-ai/core

# 2. Write a fail-closed skeleton (config + Ed25519 pair + .keyid sidecars)
npx conarium-init
export CONARIUM_AUDIT_SIGNING_KEY="$PWD/audit-ed25519.pem"

# 3. Check the install before trusting it. Until step 4 points the config at a
#    reachable DSN, doctor reports the placeholder host unreachable and exits 1.
#    That FAIL is the check working, not the install being broken — it is the one
#    thing a gateway must not be quiet about, because it keeps running with zero
#    connectors and looks healthy while serving nothing.
npx conarium-doctor

# 4. Point the generated conarium.config.json at your read-only DSN,
#    fill policy.allowTables, then run the governed MCP gateway
npx conarium

第 3 步不是装饰。缺少配置文件不会阻止网关——它以零连接器启动且不治理任何内容——而连接失败的连接器会被记录，不会被抛出。conarium-doctor 会指出两者，在有问题时退出 1 以便门控部署，并且从不打印秘密，因此其输出可以安全地粘贴到 issue 中。

git clone https://github.com/dogrucanemek-alt/conarium.git
cd conarium
npm install && npm run build
# The repository already ships a conarium.config.json, so init refuses rather
# than overwrite it (exit 1). Pass --force only if you want it regenerated.
node bin/conarium-init.mjs --force
node bin/conarium-doctor.mjs --no-net
npm start

conarium-init 拒绝覆盖已有文件，除非传入 --force。 它从不打印私钥——只打印其路径。

控制台桌面快捷方式

策略编辑器是 npx conarium-console。它仍然绑定 127.0.0.1， 并且仍然需要令牌。这两条命令只在桌面上添加一个入口：

npx conarium-console --install-shortcut
npx conarium-console --uninstall-shortcut

Windows

.lnk 桌面快捷方式（控制台窗口最小化）

macOS

~/Applications/Conarium Console.app

Linux

~/.local/share/applications/conarium-console.desktop

双击启动同一个控制台，等待端口就绪，然后 打开你的浏览器。令牌不会放入 URL；一次性 nonce（≤30 秒） 会交换为会话 cookie。如果同名快捷方式已存在， 则使用 -2 后缀，而不是覆盖。

在 --install-shortcut 之前导出 CONARIUM_CONSOLE_TOKEN，启动器 才能从 ~/.conarium/console.token（权限 0600）读取它。快捷方式 文件本身不包含令牌。

快捷方式使用 assets/conarium-mark.ico / .icns / -512.png， 它们都来自同一个 SVG。如果这些文件缺失，快捷方式仍会 创建，但命令会发出警告。

控制台 Makbuzlar 选项卡列出来自 audit.receiptSink 的已签名收据 （最新的在前），并显示与 demo.conarium.dev/proof 相同的收据 HTML。 它验证哈希链并写入 zincir sağlam 或 kırık (satır N)。 如果接收器为空或未设置，它会如实说明——它不会凭空生成 收据。审计日志仍然是未签名的游乐场痕迹；它们不是收据。

当包发布到 npm 时，相同的二进制文件将随 tarball 一起分发 （conarium-init、conarium-doctor、conarium-verify、conarium-suggest-policy）。 在那之前，请从本仓库直接运行它们。

提交 bug 之前：先运行 doctor

conarium-doctor 检查那些会静默失败的问题。其中两个最关键： 缺少配置文件不会阻止网关启动——它会以零连接器启动 并且不管理任何东西——以及 连接器无法连接时只会记录日志， 不会抛出异常，因此进程看起来一切正常，实际上什么都没服务。doctor 还会 捕获缺失的 <pubkey>.keyid 伴生文件，这会导致每张收据验证为 13（看起来像被篡改，其实没有）。

退出码 0 表示一切正常，1 表示有问题，因此它可以用于 部署门禁。它从不打印秘密——密码、令牌和密钥材料只会 以形态描述的形式报告（postgresql://appuser@db.internal:5432/prod (password set, not shown)），因此输出可以安全地粘贴到 issue 或 邮件中。

Conarium 通过 stdio 使用 MCP 协议，因此你的 AI 助手可以将其作为命令启动。将其添加到你的 MCP 客户端配置中（例如 Cursor）：

{
  "mcpServers": {
    "conarium": {
      "command": "npx",
      "args": ["-y", "--package=@conarium-ai/core", "conarium", "--config", "/path/to/your/conarium.config.json"]
    }
  }
}

⚙️ 配置（策略即代码）

使用一个简单的 conarium.json 策略文件来控制访问：

{
  "maxRows": 50,
  "allowTables": ["public.customers", "public.orders"],
  "denyTables": ["public.secrets", "public.financials"],
  "maskColumns": ["email", "ssn", "*.card", "*.api_key"],
  "protectedColumns": ["*.email", "customers.tckn"],
  "allowConnectors": ["postgres-main", "docs"]
}

allowTables 之外的任何内容默认被拒绝；匹配 maskColumns 的列会在数据到达模型之前被脱敏为 [MASKED_PII]。

protectedColumns 使用相同的 glob 语法。每个模式也会在 结果中被脱敏。此外，该列不得出现在谓词（WHERE、 HAVING、JOIN … ON、ORDER BY、GROUP BY）或派生 SELECT 表达式 中——否则查询会被拒绝。单独的 SELECT email 仍然允许，并且返回 脱敏后的结果。省略该字段，行为不变。配置文件无法设置它。 mssql / oracle 如果字段非空则拒绝启动：这些门禁无法 遍历谓词位置，而这个产品也不会声称它能执行它无法 执行的规则。

policy.dialect 选择 query 工具使用的 SQL 方言：postgres（默认，省略时）、mssql 或 oracle。这是操作者的声明——Conarium 不会从语句中猜测方言。拼写错误或 mysql 会拒绝配置。

连接器默认全部拒绝。 allowConnectors 是一个严格的允许列表： 如果缺失或为空，没有连接器被允许（以前空列表 意味着"全部允许"）。如果你配置连接器，你必须在这里列出它们—— 否则服务器拒绝启动并明确告诉你需要添加哪个字段。 denyConnectors 仍然优先于 allowConnectors。

policy.detectors 和 policy.scanCharCap

身份检测器——TCKN、IBAN、信用卡、邮箱——无法被关闭。一个试图 关闭它们的配置（detectors: { tckn: false }）会在加载时被拒绝。这就是 产品理念：银行无法通过 JSON 文件禁用的脱敏，才是真正的脱敏。

Key

Default

Why

detectors.ip

false

服务器 IP 不总是个人数据。一个无法关闭的掩码会破坏 SOC（"有多少请求来自这个地址？"）。当该列确实是客户端地址时才启用。

detectors.mrz

true

护照 MRZ 是身份信息并且包含校验位。如果你不处理旅行证件，就在基础策略中关闭它。

scanCharCap

16384

可用性。超过此长度的字段整体替换为（[MASKED_PII]），绝不跳过。环境变量 CONARIUM_SCAN_CHAR_CAP 可覆盖。提高它会使扫描成本呈二次方增长。上限 1 048 576。

{
  "scanCharCap": 32768,
  "detectors": { "ip": true }
}

policy.customPatterns

内置检测器无法识别的格式——银行客户编号、 房屋账户代码——可以注册为同一扫描器上的额外规则。这不是 第二条脱敏路径，也不会取代 maskColumns。

每条规则需要一个名称（收据中记录的内容）、一个模式、可选的 列 glob 和掩码标签。可选的 sample 是 conarium-doctor 用来测试编译后模式的样本——编译成功不等于匹配成功。一个 损坏或存在 ReDoS 风险的模式会拒绝配置；模式和 样本永远不会写入日志、收据或 doctor 输出。

{
  "customPatterns": [
    {
      "name": "teb-hesap",
      "pattern": "HSP-[0-9]{8}",
      "columns": ["*.hesap_no"],
      "label": "[MASKED_HESAP]"
    }
  ]
}

量词必须是有界的（{8}、{4,12}）。+、*、嵌套分组和 环视断言会在加载时被拒绝。规则命名的是你已经知道的格式； 它不会发明新格式。

conarium-suggest-policy --sql schema.sql 根据列名打印 maskColumns 猜测 （*name*、*address*、*tckn*、…）。它不会写入你的 配置。输出的第一行会说明这一点。

🗺️ 路线图

Conarium 是早期访问版本——并且对现状保持诚实：

当前已提供： 受治理的 MCP 网关（stdio + HTTP）· 确定性 PII 脱敏， 包括自由文本中的命名实体 · 允许/拒绝 + 行数上限 · 按人脱敏 配置文件 · 防篡改的哈希链审计账本 · 每次访问的 Ed25519 签名收据， 支持离线验证 · 签名的覆盖声明 · 与数据库自身计数器 对账的双向校验 · OpenTimestamps 锚定和可选的 锚定服务 · 一致性测试向量 · SQL 网关：Postgres、Microsoft SQL Server、Oracle （MySQL 未实现；Oracle 同义词和数据库链接不解析——见 LIMITATIONS）· Postgres、Supabase、docs、OpenAPI、Jira 和 Slack 连接器 · 通过 npx 提供的 conarium-init / conarium-doctor（@conarium-ai/core）。

下一步： 同意绑定（规范已发布，尚无代码—— 先进行专利审查）· 收据格式的第二个独立实现 · 将每用户身份绑定到身份提供者，而不是操作者令牌映射。

明确不计划实现，这样没有人会空等：

  • 基于 LLM 的"语义"脱敏。 网关刻意保持确定性。一个 概率性的掩码会产生概率性的收据，而概率性的收据不是收据。

  • 托管云控制台。 自托管是我们的承诺；托管控制台会把我们 置于我们声称不在的数据路径中。

  • 我们不追求 SOC 2。 在这个阶段，优先事项是独立的渗透 测试和实现级保证，而不是组织级认证。这关乎我们的认证， 而不是你的：签名收据和覆盖声明是你的，你可以展示给你自己的 审计师，它们是否满足某项审计要求由你和该审计师决定。如果我们 将来持有你的数据，或者某个合作取决于证书本身，这一条会最先改变。

已知差距：LIMITATIONS.md、上面的 README、 docs/RECEIPT-SPEC.md、 docs/BENCHMARK.md 和 docs/API-STABILITY.md。

📜 许可证

MIT——全部代码，包括验证器、对账工具和 锚定服务。没有任何功能被保留给付费层级；代码 就是 MIT。 conarium.dev 销售的是第二个签名者 （Pro）以及未来的托管覆盖（Business——尚未发布）——而不是 代码访问权限。

Available Tools

4 tools
describe_tableA

Get the columns of one table: name, type and description. Read-only, and it returns structure only — no row is read, so nothing here is masked. Use it to write a correct query; use list_tables first if the table name is not known. A table the policy denies returns an error rather than an empty result. Every call is written to the audit ledger, and to a signed receipt as well when a receipt sink is configured.

ParametersJSON Schema
NameRequiredDescriptionDefault
tableYesSchema-qualified table name
connectorNoConnector name (optional)

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description thoroughly discloses behavior: read-only, no row reads, no masking, error on denied tables, and audit logging. This fully compensates for lacking annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four concise sentences with high information density. Every sentence adds value: purpose, read-only assurance, usage tip, error behavior, and audit logging.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a read-only metadata tool. Covers purpose, usage order, error cases, audit trails, and privacy implications despite no annotations or output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are documented in the schema. The description mentions 'a table' and 'if the table name is not known', but adds no extra parameter-specific detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool describes columns of one table with name, type, and description. It differentiates from siblings like search, list_tables, and query by specifying its specific role in understanding table structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Use it to write a correct query' and 'use list_tables first if the table name is not known', providing clear guidance on when to use this tool vs. alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tablesA

List the database tables this gateway is allowed to expose. Read-only. Returns one entry per table with its connector, schema-qualified name and description; tables the policy denies are absent rather than marked, so this is the authoritative list of what any other tool here can reach. Call it before describe_table or query when the table names are not already known. Every call is written to the audit ledger, and to a signed receipt as well when a receipt sink is configured.

ParametersJSON Schema
NameRequiredDescriptionDefault
connectorNoConnector name (optional, defaults to all)

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Read-only,' mentions audit logging ('Every call is written to the audit ledger'), and explains that 'tables the policy denies are absent rather than marked.' These are valuable side-effect and security behaviors beyond basic operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (three sentences) and front-loaded with the core purpose. Each sentence adds value: purpose, usage guidance, return format, and behavioral notes. No fluff or redundancy, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description explicitly explains the return format ('one entry per table with its connector, schema-qualified name and description') and the denial behavior. It covers usage and side effects adequately for a simple list operation, though it omits error handling or pagination details, which slightly reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'connector' is fully described in the schema (100% coverage) as 'Connector name (optional, defaults to all).' The description adds no additional parameter meaning; it only mentions connector as part of the output structure. Since schema coverage is high, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List the database tables this gateway is allowed to expose.' It uses a specific verb (list) and resource (database tables), and explicitly distinguishes itself from siblings like describe_table and query by noting it provides the authoritative list of reachable tables. This is a model of purpose clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: 'Call it before describe_table or query when the table names are not already known.' This tells the agent when to use it (before others when names unknown), but does not explicitly state when not to use it or mention alternative tools. It implies usage context but falls short of full when/when-not coverage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

queryA

Run one read-only SELECT against the company database. Only SELECT is allowed; anything else is refused before it reaches the database. Rows come back capped by the policy (maxRows, often lower than any LIMIT you write) and protected values arrive already replaced with [MASKED_PII] or [MASKED_SECRET] — the raw values never leave the gateway, so do not plan on receiving them. A refusal is a normal outcome, not a fault. Use search instead when there is no SELECT yet and the goal is to find text. Every call is written to the audit ledger, and to a signed receipt as well when a receipt sink is configured.

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYesSQL SELECT query to execute
connectorNoConnector name (optional, defaults to first allowed)

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses multiple behavioral traits: only SELECT allowed, row caps, masking of sensitive values, refusal as normal outcome, audit logging, and optional signed receipts. It also warns that raw protected values never reach the caller, which is critical for planning. This is exceptionally transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately long but every sentence adds value: purpose, restriction, behavior, alternative, and audit trail. It is front-loaded and well-organized. Slightly verbose but not wasteful, so a 4 is warranted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose, constraints, safety features, and alternatives. Without an output schema, it doesn't specify the exact return format (e.g., column details or metadata), but it does clearly state rows come back capped and masked. Given the complexity (SQL execution with policies), it is fairly complete, though a bit more detail on response structure would be useful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — both parameters have clear descriptions in the schema. The tool description adds minimal parameter-specific detail beyond what schema provides, but it does mention the connector defaults to first allowed, which is already in the schema. Given high coverage, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs a read-only SELECT query on the database, explicitly limits to SELECT, and distinguishes from sibling tools like search (used when there is no SELECT yet). It names the resource (company database) and the verb (run), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool vs alternatives: 'Use search instead when there is no SELECT yet and the goal is to find text.' It also clarifies that refusals are normal, setting expectations for failed invocations. This is explicit and actionable guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updatesv0.2.23
    • First observeddescribe_table
    • First observedlist_tables
    • First observedquery
    • First observedsearch
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: list_tables for discovery, describe_table for schema, search for text lookup without SQL, and query for explicit SELECT statements. The description explicitly differentiates search vs query, eliminating ambiguity.

Naming Consistency5/5

All tool names follow a consistent lowercase snake_case pattern with imperative verbs: search, list_tables, describe_table, query. This is a uniform and predictable style.

Tool Count5/5

Four tools is well-scoped for a read-only database gateway: it covers table discovery, schema inspection, text search, and arbitrary SELECT queries without unnecessary bloat or gaps.

Completeness5/5

The surface is complete for its stated purpose: an agent can list tables, inspect schema, search for text, and execute read-only SQL. No dead ends or missing lifecycle operations are evident.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • @lucairn/mcp-server

    Declade
    A
    license
    A
    quality
    B
    maintenance
    Privacy-preserving AI gateway. Sanitises PII before prompts reach Anthropic / OpenAI / your LLM, then emits a signed cryptographic certificate per call (Ed25519 + RFC 3161 + Sigstore Rekor). EU GDPR + AI Act ready. Free tier 500/mo with BYOK.
    1
    2
    MIT

  • agent-sudo-mcp

    Kisyntra
    A
    license
    A
    quality
    A
    maintenance
    Local zero-trust permission gateway for AI agents. Enforces policy-based tool authorization, human approvals, scoped permissions, and cryptographically verifiable audit logs.
    4
    5
    Apache 2.0

  • Terminus

    interceptai-tech
    A
    license
    Not graded
    quality
    B
    maintenance
    A default-deny SQL firewall sidecar for AI agents that enforces per-agent policies on database queries, provides safe rewrites, and maintains a tamper-evident audit chain.
    AGPL 3.0

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dogrucanemek-alt/conarium'

If you have feedback or need assistance with the MCP directory API, please join our Discord server