Conarium

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

阅读其余内容前先验证

以下内容无需盲目信任。这里有一条实时收据链；你可以在自己的计算机上使用其公钥进行验证，无需账户，也不会使用你的任何数据：

npm i @conarium-ai/core
curl -fsS https://conarium.dev/proof/chain.jsonl   -o chain.jsonl
curl -fsS https://conarium.dev/proof/key.pem       -o key.pem
curl -fsS https://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 无法诱使它给出通过结果。请注意，它会在自身输出的第一行先主动说明自己未检查哪些内容，然后才报告好消息。

限制

本仓库尚未做到的内容见 LIMITATIONS.md （土耳其语）。带日期的对比页面位于 conarium.dev/compare.html——这是唯一副本；本仓库不另存一份。

标准

draft-dogru-scitt-disclosure-evidence 是一份个人提交，并未被 IETF 工作组采纳，也不具备正式地位——互联网草案是带有日期的公开记录，并非标准。 发布它是为了让其他人无需依赖我们也能实现该收据格式。 源文件位于 standards/。

👁️ 问题

让 Cursor 或 Copilot 连接生产数据库，它就会读取原始数据流——社保号码、信用卡号、薪资和有效密钥。一条恶意提示词就可能暴露你最敏感的数据表。安全团队根本无法允许这种情况发生。

🛡️ 解决方案：Conarium

Conarium 充当高性能的 MCP（Model Context Protocol）代理。它直接位于 AI 助手与数据库之间，以毫秒级速度评估策略，强制执行行数限制，并在传输过程中屏蔽 PII（个人身份信息）。

AI 会获得编写代码所需的上下文；策略保护的值会在传给 AI 之前被屏蔽。屏蔽会隐藏一个值，但不会让它变得不可学习；而且，如果请求语言允许对受保护列使用谓词，获准的查询仍可能回答有关该列的问题。对此，更有针对性的解决方案是 protectedColumns，相关限制已在 LIMITATIONS.md 中说明，而不是留给你自行发现。

主要功能

• 内联 PII 屏蔽： 在模型看到任何字符之前，电子邮件、ID、卡号和密钥就会在响应流中被替换为 [MASKED_PII] / [MASKED_SECRET]。
• 允许 / 拒绝列表： 将 AI 可访问的内容列入白名单。你的 secrets 和 financials 表会保持不可见。
• 行数上限： 对每个查询设置硬性限制，防止数百万行数据在不知不觉中被外传。
• 防篡改审计账本： 通过 Conarium 发生的每次访问都会被记录（谁、什么、何时、行数、决策）。账本采用哈希链，因此可检测篡改和链中数据移除——但这并非不可能：磁盘上的文件仍可被删除或截断；要检测截断，需要一个保存在文件之外的锚点（参见下文“覆盖范围与对账”）。保障 PII 安全：日志中不会写入原始 PII。
• 可验证收据： 使用 Ed25519 签名、可独立验证的收据——见下文。
• 按人员配置的屏蔽配置文件： 对 AI Agent 屏蔽的内容，不一定要对数据控制者屏蔽。命名配置文件可放宽对某一名已识别人员的屏蔽，收据会记录应用了哪个配置文件——见下文。
• 覆盖范围与对账： 针对收据链的签名覆盖范围声明（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/ 是规范依据。

锚定是一个独立步骤。使用 npx conarium-stamp <file> 为文档加盖时间戳，或使用 npx conarium-anchor-service 提交链头哈希。 CONARIUM_ANCHOR_SINK=opentimestamps 会选择这些工具所用的内置日历客户端；它不会在写入回执时为回执加盖时间戳。之后可使用 npx conarium-anchor-upgrade ./audit.jsonl.anchors.jsonl 升级待处理的证明。 客户端内置于项目中（Node crypto + 日历 HTTPS）。它不会安装 javascript-opentimestamps。请参阅 LIMITATIONS.md。

按个人配置脱敏

对 AI Agent 来说正确的脱敏方式，对数据所有者本人来说却是错误的。 需要了解 “哪个客户欠款最多” 的所有者需要看到姓名；汇总营收的助手则不需要。用全局开关来回答这个问题会关闭产品唯一真正的保障，因此脱敏按个人解析：

{
  "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": { "alice": "controller-full" }
  }
}

有意限定了范围，因为这是唯一可能降低保护级别的功能：

• 配置文件只能覆盖 maskColumns、maxRows 和 maskLabelledNames，除此之外不能覆盖任何内容。 表、工具和连接器的权限仍是全局设置；配置文件绝不能扩大可访问范围，只能调整其中内容的可读性。 protectedColumns 不可通过配置文件覆盖：如果配置文件能移除它，就会成为按个人设置的后门。
• 仅限个人令牌。 使用共享令牌进行身份验证的主体永远不会获得配置文件。“谁持有这个字符串，谁就能看到未脱敏的 PII”正是本产品旨在防止的问题。
• 其他情况一律默认拒绝： 没有主体、主体未列入清单，或配置文件名称不存在时，都会回退到基础策略，绝不会回退到保护范围更宽的策略。
• 内容扫描器仍会运行。 电子邮件／国家身份证号／电话号码／银行卡／IBAN／机密信息检测器完全不可覆盖，因此无论应用了哪个配置文件，这些内容在自由文本中都会保持脱敏。只有符合 ISO 7064 mod-97-10 校验规则时，IBAN 才会被接受。护照机读区（MRZ）（TD3，7-3-1 校验位）默认启用，同样不能通过配置文件关闭——只有在基础策略中设置 policy.detectors.mrz: false 才能选择退出。IP 地址默认关闭，只有设置 policy.detectors.ip: true 才会启用。姓名脱敏是唯一可由配置文件关闭的检测器（maskLabelledNames: false），因为控制者查看自己的客户名单正是此功能存在的理由。
• 回执会说明应用了哪个配置文件——policy.id 会变为 conarium.policy/<profile>，并包含在签名哈希中。使用宽松配置文件进行的访问，之后不能被说成是经过了完整脱敏。这让审计记录真实可信：重点从来不是“没人能看到 PII”，而是“每次访问都受规则约束，并且证据会说明适用的是哪套规则。”

自由文本中的姓名

其他每种标识符都有固定形式。电子邮件地址带有 @，国民身份证号有校验位，银行卡号有长度限制——正则表达式据此判断，而且判断结果可复现。姓名没有固定形式，因此只有 maskColumns 能捕捉姓名，而输入自由文本 note 中的姓名会原样传给模型。

以下两个确定性处理阶段，诚实地弥补了这方面能够弥补的部分：

刻意不做的一点：不会检测普通行文中没有标记的姓名。“Ahmet called yesterday”会直接通过。要捕捉这类内容，需要 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 并不总是个人数据，而且无法禁用的屏蔽会妨碍 SOC 工作。1.2.3.4 在结构上是有效的 IPv4 地址；启用检测器后，即使你指的是版本号，也会被屏蔽。日期（13.08.2026）和金额（1.250,00）不是 IPv4 地址。

自由文本中的护照号码不会被捕捉。**MRZ 会被捕捉：**两行 TD3 × 每行 44 个字符，第 1 位为 P，校验位遵循 7-3-1 规则。校验失败就不算 MRZ，会保持原样。尚未实现 TD1/TD2。

位于电子邮件地址格式标记中的 HTML @ / @、JSON \u0040 和 %40 会被屏蔽。孤立的 5@ store 或 C:\path\u0040abc 会保持原样。只解码一次；不会继续处理 @。

如果同一行中两个名称相似的字段（tckn_1 / tckn_2）拼接后校验通过，则其中拆分的 TCKN 会被屏蔽。无关列不会拼接。

零宽字符、全角数字 / ＠ 和 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 天内可无条件退款；此后不提供部分退款。适用时需另加 VAT。目前尚未开放结账： conarium.dev/buy会跳转到候补名单表单，直到付款流程正式上线。因此，这些是已公布的价格，并非你今天就能支付的价格。上面的二进制文件供你自行运行；Pro 则提供第二位签署方。该功能自 0.2.16 起随软件包发布；由 VERAX 运营的端点目前尚未向客户开放。Business 用户仍在候补名单上：定期对账、覆盖范围警报和签名期间报告均包含在合同中，但尚未发布。

自行实现此格式

回执的设计初衷是让它比当前实现存在得更久，因此随附了一组符合性测试向量——十三个冻结用例，以及 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-Drafts。相关研究：Aegon（arXiv 2604.06693）、去中心化信任层 （ACM Web Conf 2026），以及关于签名同意记录的 ISO/IEC TS 27560:2023。

这些回执证明 Agent 做了什么。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 日核查，Vaara 于 8 月 19 日加入——说明各项目具备什么、最接近的学术先例（Sello / Notarized Agents，它对这一空白的表述比我们更准确），以及九项我们无法核实的内容。如果你知道有实现同时具备这三项能力，请提交一个 issue，我们会更正。

⚠️ Vaara 这一行缩小了这项主张的范围，而非证实它。该项目的设计文档中说明了覆盖范围核对的方案；搜索其代码树后，没有找到运行该方案的代码，因此这一行写的是“已说明，未发现已实现”。这个想法并非只有我们提出——据此次扫描所及，仍只有我们提供了可运行的代码；文件也在表格上方说明了这一点。

🏗️ 架构（三位一体）

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. 网关： 一个能够流畅对接大模型助手的代理。
2. 引擎： 在毫秒内评估 JSON 策略、正则表达式扫描和行数上限。
3. 账本： 一份防篡改审计日志，记录其处理的每一次查询和决策。

无需数据库，立即试用

npx -y --package=@conarium-ai/core conarium --demo

使用示例行而非数据库启动本地 MCP 服务。对于获准访问的表，行在离开网关前会先对电子邮件和卡号值进行掩码处理；被拒绝访问的表会被拒绝；行数上限会生效；获准和被拒绝的调用都会记录在签名链上。不会使用任何已提供的连接器。

{
  "mcpServers": {
    "conarium": {
      "command": "npx",
      "args": ["-y", "--package=@conarium-ai/core", "conarium", "--demo"]
    }
  }
}

🚀 快速开始

# 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 退出，因此可用于拦截部署；它绝不会打印密钥，因此其输出可以安全地粘贴到问题中。

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

除非传入 --force，否则 conarium-init 不会覆盖现有文件。 它绝不会打印私钥，只会显示其路径。

控制台桌面快捷方式

策略编辑器的启动命令是 npx conarium-console。它仍绑定到 127.0.0.1， 仍需要令牌。以下两个命令只会在桌面上添加一个入口：

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

双击后会启动同一个控制台，等待端口开始监听，然后打开浏览器。令牌不会放入 URL；系统会使用一次性 nonce（≤30s）换取会话 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)。 如果接收器为空或未设置，它会如实说明，不会编造示例回执。Audit Logs 仍是未签名的试验记录；它们不是回执。

当软件包发布到 npm 后，这些二进制文件也会包含在 tarball 中（conarium-init、conarium-doctor、conarium-verify、conarium-suggest-policy）。 在此之前，请按上述方式从此仓库运行它们。

提交 Bug 前：运行 doctor

conarium-doctor 会检查那些可能悄无声息地失败的项目。其中最重要的是两项： 缺少配置文件不会阻止网关启动——它会以零个连接器启动，且不管理任何内容——而无法连接的连接器只会记录日志，不会抛出错误，因此进程看起来运行正常，实际上却什么也没提供。doctor 还会检查是否缺少 <pubkey>.keyid 伴随文件；缺少该文件会导致每份回执验证结果都为 13（看起来像遭到篡改，实际上并非如此）。

无问题时它以 0 退出，出现问题时以 1 退出，因此可用于拦截部署。它绝不会打印密钥——密码、令牌和密钥材料只会以类型信息的形式报告（postgresql://[email protected]:5432/prod (password set, not shown)），因此输出可以安全地粘贴到问题或电子邮件中。

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 文件关闭的遮蔽功能，就不算真正的遮蔽。

{
  "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 会根据列名（*name*、*address*、*tckn*，等等）打印一个 maskColumns 建议。它不会写入你的配置。输出的第一行会说明这一点。

🗺️ 路线图

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 认证。**现阶段的优先事项是独立渗透测试和实现层面的保障，而非组织认证。这里说的是我们自己的认证，不是你们的：已签名的回执和覆盖范围声明由你们提供给自己的审计员；它们是否满足特定审计要求，由你们和审计员决定。如果我们开始持有你们的数据，或者某项合作的成败取决于证书本身，我们会优先调整这一点。
• **上方的 OpenSSF Best Practices 徽章代表自我认证，而非审计。**我们回答了其中的 67 个问题，并公开了答案；任何人都可以在项目 14160查看，并逐项对照此代码库进行核验。这有一定价值——这些答案可以被证伪——但这不等同于由独立第三方审查。67 个问题中有 3 个标记为不适用，并说明了原因。旁边的 Scorecard 徽章由机器测量，其中 Code-Review 得分为 0，因为这里的拉取请求在没有第二位审批者的情况下就会合并。

已知缺口：LIMITATIONS.md、上方的 README、 docs/RECEIPT-SPEC.md、 docs/BENCHMARK.md 和 docs/API-STABILITY.md。

📜 许可证

MIT——全部内容均采用 MIT 许可证，包括验证器、核对工具和锚定服务。没有任何功能被留作付费版本专享；代码采用 MIT 许可证。conarium.dev销售的是第二个签名者（Pro），以及之后推出的托管覆盖服务（Business——尚未发布），而不是代码访问权。