Skip to main content
Glama

사이트는 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 워킹 그룹에서 채택되지 않았으며 공식적인 지위를 갖지 않습니다 — 인터넷 초안(Internet-Draft)은 날짜가 찍힌 공개 기록이지 표준이 아닙니다. 영수증 형식을 우리 없이도 구현할 수 있도록 게시된 것입니다. 소스 파일은 standards/에 있습니다.

👁️ 문제

Cursor나 Copilot을 프로덕션 데이터베이스에 연결하면 원시 스트림을 그대로 마시게 됩니다—주민등록번호, 신용카드, 급여, 실시간 키까지. 악의적인 프롬프트 하나로 가장 민감한 테이블이 노출될 수 있습니다. 보안 팀은 그런 상황을 절대 허용할 수 없습니다.

🛡️ 해결책: Conarium

Conarium은 고성능 MCP(Model Context Protocol) 프록시 역할을 합니다. AI 어시스턴트와 데이터베이스 사이에 직접 위치하여 정책을 밀리초 단위로 평가하고 행 제한을 적용하며 PII(개인 식별 정보)를 전송 중에 마스킹합니다.

AI는 코드를 작성하는 데 필요한 컨텍스트를 얻고, 여러분의 정책이 보호하는 값은 모델에 도달하기 전에 마스킹됩니다. 마스킹은 값을 숨길 뿐, 학습 불가능하게 만들지는 않습니다. 또한 요청 언어가 보호된 열에 대한 조건을 허용하는 경우, 허용된 쿼리로도 해당 열에 대한 질문에 답할 수 있습니다. protectedColumns는 이에 대한 더 좁은 해결책이며, 그 한계는 여러분이 직접 발견하도록 내버려 두지 않고 LIMITATIONS.md에 명시되어 있습니다.

주요 기능

  • 인라인 PII 마스킹: 이메일, ID, 카드, 비밀 값이 모델이 한 글자라도 보기 전에 응답 스트림에서 삭제됩니다([MASKED_PII] / [MASKED_SECRET]).

  • 허용/거부 목록: AI가 접근할 수 있는 것을 화이트리스트로 관리합니다. secretsfinancials 테이블은 보이지 않게 유지됩니다.

  • 행 상한: 쿼리당 하드 제한. 수백만 행의 조용한 유출을 방지합니다.

  • 변조 감지 감사 원장: Conarium을 통한 모든 접근이 기록됩니다(누가, 무엇을, 언제, 행 수, 결정). 해시 체인 방식으로, 변경 및 체인 중간에서의 제거를 감지할 수 있습니다 — 불가능한 것은 아닙니다: 디스크의 파일은 여전히 삭제되거나 잘릴 수 있으며, 잘림을 감지하려면 파일 외부의 핀(pin)이 필요합니다(아래 Coverage & Reconciliation 참조). PII 안전: 원시 PII는 로그에 기록되지 않습니다.

  • 검증 가능한 영수증: Ed25519 서명, 독립적으로 검증 가능한 영수증 — 아래 참조.

  • 사람별 마스킹 프로필: AI 에이전트에 대해 마스킹할 것은 데이터 컨트롤러에 대해 마스킹할 것과 다릅니다. 명명된 프로필은 식별된 한 사람에 대해 마스킹을 완화하며, 영수증에는 어떤 프로필이 적용되었는지 기록됩니다 — 아래 참조.

  • Coverage & Reconciliation: 영수증 체인에 대한 서명된 커버리지 선언(conarium-coverage)과 데이터베이스 자체 쿼리 카운터에 대한 양방향 조정(conarium-reconcile) — 어떤 영수증으로도 커버되지 않는 DB 기록 활동이 보이지 않는 상태로 남는 대신 표면화됩니다.

  • 100% 자체 호스팅: 전적으로 여러분의 인프라에서 실행됩니다. 우리가 배포하는 어떤 것도 여러분의 데이터를 외부로 전송하지 않습니다: 원시 보호 값은 여러분의 경계 안에 머물며, AI 클라이언트에 도달하는 것은 정책이 승인한 공개(disclosure)입니다 — 그 정확한 바이트는 영수증에 기록됩니다(disclosure.hash). 데이터가 전혀 나가지 않는다고 말하는 것은 잘못된 주장일 것입니다: 관리되는 공개를 어시스턴트에게 전달하는 것이 바로 이 제품의 역할입니다. 게이트웨이는 여러분의 것이 아닌 외부 요청을 정확히 하나만 만듭니다: 시작 시 공개 npm 레지스트리에 최신 버전이 있는지 묻고, 있으면 stderr에 한 줄을 출력합니다. 여러분에 대해 아무것도 보내지 않습니다 — 식별자, 구성, 수치 모두 없음 — 그리고 몇 주 동안 아무도 보지 않는 원격 게이트웨이가 바로 이 기능이 존재하는 이유입니다. CONARIUM_NO_UPDATE_CHECK=1로 비활성화하거나 CONARIUM_NPM_REGISTRY로 내부 미러를 지정할 수 있습니다. 2초 타임아웃이 있으며 시작을 차단하거나 실패시키지 않습니다. 공개되지 않은 외부 연결을 만드는 거버넌스 제품은 이미 논쟁에서 진 것이기 때문에 여기에 명시합니다.

  • MCP 네이티브: Cursor, GitHub Copilot, Claude Code, Codex와 즉시 호환됩니다.

검증 가능한 영수증

Conarium은 휴대용 영수증(Art. 12 / 19 형식)을 발행할 수 있으며, 제3자가 Conarium 설치 없이 단일 파일로 오프라인 검증할 수 있습니다.

공식 주장(확대하지 마세요): Conarium 영수증은 파일에 여전히 있는 레코드가 생성된 후 변경, 재정렬, 소급 날짜 지정되지 않았으며 체인 중간에서 제거되지 않았음(prevHash / seq)을 증명합니다. 생성 당시에 정확했다는 것은 증명하지 않습니다. 또한 레코드가 끝에서 삭제되지 않았음을 단독으로 증명할 수 없습니다: 더 짧아진 남은 체인도 내부적으로는 일관성이 있기 때문입니다. 꼬리 잘림을 감지하려면 파일 외부의 핀(pin)이 필요합니다 — --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/가 계약(contract)입니다.

옵트인 앵커링: CONARIUM_ANCHOR_SINK=opentimestamps. 보류 중인 증명은 나중에 npx conarium-anchor-upgrade ./audit.jsonl.anchors.jsonl로 업그레이드하세요. 클라이언트는 트리 내에 있습니다(Node crypto + calendar 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를 본다"는 것은 정확히 이 제품이 방지하기 위해 존재하는 실패입니다.

  • 그 외 모든 곳에서는 실패 시 잠금(fail-closed): 행위자 없음, 목록에 없는 행위자, 존재하지 않는 프로필 이름 — 모두 기본 정책으로 폴백되며, 더 넓은 정책으로는 절대 폴백되지 않습니다.

  • 콘텐츠 스캐너는 계속 실행됩니다. 이메일 / 주민등록번호 / 전화 / 카드 / 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를 보지 못한다"가 아니라 "모든 접근이 관리되며, 증거는 어떤 규칙 하에서였는지 말해준다"는 것입니다.

자유 텍스트의 이름

다른 모든 식별자는 형태(shape)가 있습니다. 이메일에는 @가 있고, 주민등록번호에는 체크섬이 있으며, 카드에는 길이가 있습니다 — 정규식이 결정하고, 그 결정은 재현됩니다. 이름에는 형태가 없으므로 maskColumns가 이름을 잡는 유일한 수단이었고, 자유 텍스트 note에 입력된 이름은 그대로 모델에 도달했습니다.

두 가지 결정론적 패스가 정직하게 닫을 수 있는 그 간극의 일부를 닫습니다:

패스

트리거 조건

예시

이월(Carry-over)

값이 이 정책이 이미 일부 열에서 마스킹하는 값인 경우

customer_name이 마스킹되므로 note: "Ayşe Demir called"도 마스킹됩니다 — 행을 넘어서도

라벨링(Labelled)

텍스트 자체가 표시하는 경우: 호칭 또는 필드 라벨

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가 항상 개인정보인 것은 아니며, 비활성화할 수 없는 마스크는 SOC 작업을 방해합니다. 1.2.3.4는 구조적으로 유효한 IPv4 주소이므로, 버전 번호를 의미했더라도 감지기가 켜져 있으면 마스킹됩니다. 날짜(13.08.2026)와 금액(1.250,00)은 IPv4가 아닙니다.

자유 텍스트의 여권 번호는 잡히지 않습니다. MRZ는 잡힙니다: 2개의 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_1 / tckn_2)에 걸쳐 분할된 TCKN은 연결된 값의 체크섬이 일치할 때 마스킹됩니다. 관련 없는 열은 결합하지 않습니다.

제로 폭 문자, 전자 문자 숫자 / , 유니코드 대시는 감지기 이전에 제거되거나 ASCII로 매핑됩니다 — 이 패스는 일반적인 인코딩 디코더가 아닙니다. 필드 내부의 래핑된 base64/hex 토큰은 기존 감지기 적중으로 디코딩될 때만 마스킹됩니다.

스캔 길이. policy.scanCharCap(기본값 16,384자, 환경 변수 CONARIUM_SCAN_CHAR_CAP으로 재정의)보다 긴 단일 텍스트 필드는 식별자가 없더라도 전체가 [MASKED_PII]로 대체됩니다. 스캐너를 건너뛰지 않습니다. 건너뛴다면 긴 메모, JSON 블롭, 로그 라인이 마스킹을 우회하는 수단이 되기 때문입니다. 이는 사용성 설정입니다. 값을 올리면 스캔 비용이 이차 함수적으로 증가합니다 — 40KB 영숫자 필드는 이메일 정규식에 상한을 두기 전에는 무제한 이메일 정규식에서 약 1초가 걸렸습니다. maskedCount는 결정이 내려졌음을 기록합니다.

이월(carry-over)은 3자 미만의 값은 무시하며(2자 값은 모든 곳에서 일치하여 출력을 파괴함) 유니코드 단어 경계에서 일치하므로 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

언어는 의도적입니다: 부재는 "접근 기록 없음(NOT RECORDED)" / "영수증 미발행(not receipted)" 으로 보고되며, 결코 "접근이 발생하지 않음"으로 보고되지 않습니다 — 부재 기록은 본질적으로 모호하며, 그 반대인 척하는 도구는 감사자에게 거짓말을 하는 것입니다.

출시 당일 자사 프로덕션 ERP에 대해 실행했으며, 우리 스스로 수행한 실제 우회 공격과 도구가 이를 포착한 사례가 포함되어 있습니다: docs/dogfood/2026-08-06-reconcile.md.

전체 스키마, 종료 코드 및 알려진 공백: docs/RECEIPT-SPEC.md.

부서명 (스스로 할 수 없는 부분)

영수증은 게이트웨이를 통과한 것을 증명합니다. 조정은 우회한 것이 없음을 증명합니다. 둘 다 귀하의 것이며, 자체 호스팅되고, 귀하의 키로 서명됩니다 — 이것이 바로 감사자가 할인해 보는 부분입니다: 귀하가 기록을 보관하고, 서명하고, 저장했습니다. 부서명은 동일한 체인 헤드에 제2의 당사자를 두어 이에 대응합니다.

서비스는 이 패키지에 포함되어 있으므로 직접 실행하고 자신의 헤드에 서명할 수 있습니다 — 두 번째 내부 관리인에게는 유용하고, 위의 이의 제기에는 무의미합니다. 가치가 있는 이유는 서명자가 귀하가 아니기 때문입니다.

# 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 운영 엔드포인트는 아직 고객에게 공개되지 않았습니다. 비즈니스는 대기자 명단에 남아 있습니다: 예약 조정, 적용 범위 경고, 서명된 기간 보고서는 계약에 포함되어 있으며 아직 출시되지 않았습니다.

형식을 직접 구현하기

영수증은 이 구현보다 오래 지속되도록 설계되었으므로 적합성 테스트 벡터(12개의 고정 사례와 기계 판독 가능한 매니페스트)와 함께 제공됩니다: 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를 제공하고, 타이머로 보류 중인 앵커를 업그레이드합니다.

이것은 우리가 운영하는 서비스가 아니라 실행하는 코드입니다 — 가입할 호스팅 인스턴스가 없습니다. 또한 제3자가 참조 OpenTimestamps 클라이언트로 확인하고 서비스를 완전히 무시할 수 있도록 원시 증명을 제공합니다. 신뢰해야 하는 앵커링 엔드포인트는 앵커링의 목적을 무너뜨릴 것입니다.

서명은 실패 시 폐쇄(fail-closed)됩니다: 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 인터넷 초안을 보유하고 있습니다. 관련 연구: 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개 필드 마스킹, 모델 유출 0건(거버넌스 보고서 001).

그 숫자가 무엇인지, 무엇이 아닌지. 이는 자사 ERP에 대한 배치 실행에서 비롯되었으며, 이를 뒷받침하는 것은 직접 다시 더해볼 수 있는 산술을 가진 123줄의 해시 체인 감사 파일이며, 그 체인은 17일 후에 다시 검증되었습니다. 이를 뒷받침하지 않는 것은 영수증 체인입니다: 해당 실행은 서명된 이식 가능한 영수증이 아닌 감사 항목을 생성했으며, 그 행위자는 사람이 아닌 배치 서비스 ID입니다. 따라서 "그 485,496개 필드에 대한 영수증을 보여주세요"라고 묻는다면, 정직한 대답은 존재하지 않는다는 것입니다 — 영수증 체인은 별개의 훨씬 작은 측정입니다. 규모와 오프라인 검증 가능성은 여기서 서로 다른 두 가지 주장이며, 우리는 귀하가 발견할 때까지 기다리기보다 스스로 그 선을 긋는 편을 택합니다. 메커니즘은 우리를 신뢰하지 않아도 검증할 수 있습니다. 이 특정 수치는 우리 자체 측정이며, 거버넌스 보고서 001에 그 한계가 나열되어 있습니다.

그 주장은 의도적으로 회의적으로 표현되었으며, docs/PRIOR-ART.md가 그 증거입니다: 2026년 8월 6일에 확인한 10개 프로젝트, 각각이 가진 것, 가장 가까운 학술적 선행 연구(Sello / Notarized Agents — 우리보다 이 격차를 더 잘 지적함), 그리고 검증할 수 없었던 9가지. 세 가지를 모두 결합한 구현을 알고 있다면 이슈를 열어 주시면 수정하겠습니다.


🏗️ 아키텍처 (트라이어드)

Conarium은 세 기둥 사이에 권력을 균형 있게 배분하는 엄격한 3자 아키텍처로 작동합니다:

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단계는 장식이 아닙니다. 구성 파일이 없어도 게이트웨이는 중지되지 않습니다 — 커넥터가 0개인 상태로 시작되어 아무것도 관리하지 않으며, 연결에 실패한 커넥터는 예외를 발생시키지 않고 기록됩니다. 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

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초)가 세션 쿠키로 교환됩니다. 같은 이름의 바로가기가 이미 있으면 덮어쓰는 대신 -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). 그때까지는 위와 같이 이 저장소에서 실행하세요.

버그를 제보하기 전에: doctor 실행

conarium-doctor는 조용히 실패하는 항목들을 검사합니다. 그중 두 가지가 가장 중요합니다: 구성 파일이 없어도 게이트웨이는 중단되지 않습니다 — 커넥터가 0개인 상태로 시작되어 아무것도 관리하지 않으며, 연결할 수 없는 커넥터는 예외를 발생시키지 않고 로그만 기록되므로 프로세스는 아무것도 제공하지 않으면서 정상으로 보입니다. doctor는 또한 누락된 <pubkey>.keyid 사이드카를 잡아내는데, 이로 인해 모든 영수증이 13으로 검증됩니다(변조처럼 보이지만 실제로는 아닙니다).

정상이면 0으로 종료되고 문제가 있으면 1로 종료되므로 배포 게이트로 사용할 수 있습니다. 비밀은 절대 출력하지 않습니다 — 비밀번호, 토큰, 키 자료는 형태만 보고됩니다(postgresql://appuser@db.internal: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"]
    }
  }
}

⚙️ 구성 (Policy as Code)

간단한 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.dialectquery 도구가 사용하는 SQL 게이트를 선택합니다: postgres (생략 시 기본값), mssql, 또는 oracle. 이는 운영자의 선언입니다 — Conarium은 문장에서 방언을 추측하지 않습니다. 오타나 mysql은 구성을 거부합니다.

커넥터는 fail-closed입니다. allowConnectors는 엄격한 허용 목록입니다: 누락되거나 비어 있으면 어떤 커넥터도 허용되지 않습니다(이전에는 빈 목록이 "모두 허용"을 의미했습니다). 커넥터를 구성하는 경우 여기에 나열해야 합니다 — 그렇지 않으면 서버가 시작을 거부하고 추가해야 할 필드를 정확히 알려줍니다. denyConnectors는 여전히 allowConnectors보다 우선합니다.

policy.detectorspolicy.scanCharCap

신원 탐지기 — TCKN, 카드, IBAN, 이메일 — 는 끌 수 없습니다. 끄려는 구성 (detectors: { tckn: false })은 로드 시 거부됩니다. 이것이 제품의 정체성입니다: 은행이 JSON 파일 하나로 비활성화할 수 있는 마스킹은 마스킹이 아닙니다.

기본값

이유

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, 마스크 레이블이 필요합니다. 선택적 sampleconarium-doctor가 컴파일된 패턴을 시도해 보는 값입니다 — 컴파일 성공이 전부는 아닙니다. 깨졌거나 ReDoS 형태의 패턴은 구성을 거부합니다. 패턴과 샘플은 로그, 영수증, doctor 출력에 절대 기록되지 않습니다.

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

수량자는 제한되어야 합니다({8}, {4,12}). +, *, 중첩 그룹, lookaround는 로드 시 거부됩니다. 규칙은 이미 알고 있는 형식의 이름을 지정하는 것이지 새로운 형식을 만들어내는 것이 아닙니다.

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-ai/core)를 통한 conarium-init / conarium-doctor.

다음 단계: 동의 바인딩(사양 게시됨, 코드 없음 — 특허 검토 우선) · 영수증 형식의 두 번째 독립 구현 · 운영자 토큰 맵이 아닌 ID 공급자에 바인딩된 사용자별 ID.

의도적으로 계획하지 않음, 아무도 기다리지 않도록:

  • 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

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

Related MCP Connectors

Related MCP Servers

  • 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
  • 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
  • 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