Skip to main content
Glama

Die Website befindet sich unter conarium.dev; dieses Repository ist das Produkt.

Überprüfen Sie es, bevor Sie den Rest lesen

Nichts unten muss auf Treu und Glauben genommen werden. Es gibt eine Live-Quittungskette; verifizieren Sie sie mit ihrem öffentlichen Schlüssel auf Ihrem eigenen Rechner, ohne Konto und ohne Ihre Daten:

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)

Exit-Code 0. Die drei Quittungen sind ein gewöhnlicher Lesevorgang, einer, bei dem fünf E-Mail-Adressen und eine Kartennummer maskiert wurden, bevor das Modell sie sah, und eine Ablehnung. Ändern Sie ein beliebiges Feld, und der neu berechnete Hash stimmt nicht mehr mit dem gespeicherten überein — Exit 10. Ändern Sie stattdessen die Signatur — Exit 13.

Der Verifizierer ist eine einzelne Datei, die nichts aus dem Paket importiert, das sie prüft, sodass ein kompromittiertes Conarium es nicht zu einem bestandenen Ergebnis überreden kann. Beachten Sie, dass es in der ersten Zeile seiner eigenen Ausgabe freiwillig angibt, was es nicht geprüft hat, bevor es die gute Nachricht verkündet.

Related MCP server: @lucairn/mcp-server

Einschränkungen

Was dieses Repository nicht getan hat, steht in LIMITATIONS.md (Türkçe). Die datierte Vergleichsseite ist conarium.dev/compare.html — das ist die einzige Kopie; dieses Repository führt keine zweite.

Standards

draft-dogru-scitt-disclosure-evidence ist eine individuelle Einreichung. Nicht von einer IETF-Arbeitsgruppe übernommen und ohne formellen Status — ein Internet-Draft ist ein datierter öffentlicher Datensatz, kein Standard. Er wird veröffentlicht, damit das Quittungsformat ohne uns implementiert werden kann. Quelldateien befinden sich in standards/.

👁️ Das Problem

Richten Sie Cursor oder Copilot auf eine Produktionsdatenbank, und es trinkt den rohen Datenstrom – SSNs, Kreditkarten, Gehälter und Live-Schlüssel. Ein einziger bösartiger Prompt kann Ihre sensibelsten Tabellen offenlegen. Sicherheitsteams können das einfach nicht zulassen.

🛡️ Die Lösung: Conarium

Conarium fungiert als leistungsstarker MCP (Model Context Protocol) Proxy. Es sitzt direkt zwischen dem KI-Assistenten und Ihren Datenbanken, bewertet Richtlinien in Millisekunden, um Zeilenlimits durchzusetzen und PII (Personenbezogene Daten) während der Übertragung zu maskieren.

Die KI erhält den Kontext, den sie zum Schreiben von Code benötigt; die Werte, die Ihre Richtlinie schützt, werden maskiert, bevor sie sie erreichen. Maskierung verbirgt einen Wert – sie macht ihn nicht unerlernbar, und wo eine Abfragesprache Prädikate über eine geschützte Spalte erlaubt, kann eine zulässige Abfrage dennoch Fragen zu einer solchen beantworten. protectedColumns ist die engere Antwort darauf, und die Grenze wird in LIMITATIONS.md angegeben, statt dass Sie sie selbst entdecken müssen.

Hauptfunktionen

  • Inline-PII-Maskierung: E-Mails, IDs, Karten und Geheimnisse werden im Antwortstrom redigiert ([MASKED_PII] / [MASKED_SECRET]), bevor das Modell auch nur ein Zeichen sieht.

  • Erlaubnis-/Verbotslisten: Whitelist, was die KI zugreifen darf. Ihre secrets- und financials-Tabellen bleiben unsichtbar.

  • Zeilenlimits: Harte Grenzen pro Abfrage. Verhindern die stille Exfiltration von Millionen von Zeilen.

  • Manipulationssicheres Audit-Ledger: Jeder Zugriff durch Conarium wird protokolliert (wer, was, wann, Zeilen, Entscheidung). Hash-verkettet, was Änderungen und Entfernungen in der Mitte erkennbar macht – nicht unmöglich: Eine Datei auf der Festplatte kann immer noch gelöscht oder abgeschnitten werden, und das Erkennen von Abschneiden erfordert einen Anker von außerhalb der Datei (siehe Coverage & Reconciliation unten). PII-sicher: Keine rohen PII werden in die Logs geschrieben.

  • Verifizierbare Quittungen: Ed25519-signierte, unabhängig verifizierbare Quittungen – siehe unten.

  • Personenbezogene Maskierungsprofile: Was für einen KI-Agenten maskiert werden muss, ist nicht dasselbe wie für den Datenverantwortlichen. Ein benanntes Profil lockert die Maskierung für eine identifizierte Person, und die Quittung zeichnet auf, welches Profil angewendet wurde – siehe unten.

  • Coverage & Reconciliation: Eine signierte Coverage-Erklärung über die Quittungskette (conarium-coverage), plus zweiseitige Abgleich mit den eigenen Abfragezählern der Datenbank (conarium-reconcile) – DB-aufgezeichnete Aktivität, die von keiner Quittung abgedeckt wird, wird sichtbar gemacht, statt unsichtbar zu bleiben.

  • 100% selbst gehostet: Läuft vollständig auf Ihrer Infrastruktur. Nichts, was wir ausliefern, überträgt Ihre Daten irgendwohin: Rohe geschützte Werte bleiben innerhalb Ihrer Grenzen, und was Ihren KI-Client erreicht, ist die richtlinienkonforme Offenlegung – deren exakte Bytes die Quittung aufzeichnet (disclosure.hash). Zu behaupten, Ihre Daten verlassen das System nie, wäre die falsche Aussage: Eine regierte Offenlegung an einen Assistenten freizugeben, ist die Aufgabe. Das Gateway macht genau eine ausgehende Anfrage, die nicht Ihre ist: Beim Start fragt es die öffentliche npm-Registry, ob eine neuere Version existiert, und gibt gegebenenfalls eine Zeile auf stderr aus. Es sendet nichts über Sie – keine Kennung, keine Konfiguration, keine Zähler – und ein entferntes Gateway, das wochenlang niemand ansieht, ist der Grund, warum es überhaupt existiert. Deaktivieren Sie es mit CONARIUM_NO_UPDATE_CHECK=1 oder richten Sie es mit CONARIUM_NPM_REGISTRY auf Ihren internen Spiegel. Es hat ein 2-Sekunden-Timeout und blockiert oder scheitert nie beim Start. Wir listen es hier auf, weil ein Governance-Produkt, das eine nicht offengelegte ausgehende Verbindung herstellt, das Argument bereits verloren hat.

  • MCP-nativ: Funktioniert sofort mit Cursor, GitHub Copilot, Claude Code und Codex.

Verifizierbare Quittungen

Conarium kann tragbare Quittungen (Art. 12 / 19 geformt) ausgeben, die ein Dritter offline mit einer einzigen Datei verifiziert – keine Conarium-Installation erforderlich.

Offizielle Aussage (nicht erweitern): Eine Conarium-Quittung beweist, dass die noch in der Datei befindlichen Datensätze nach ihrer Erstellung nicht verändert, neu angeordnet oder rückdatiert wurden und dass keiner aus der Mitte der Kette entfernt wurde (prevHash / seq). Sie beweist nicht, dass sie im Moment der Erstellung korrekt waren. Sie kann auch nicht allein beweisen, dass keine Datensätze vom Ende entfernt wurden: Eine kürzere übrig gebliebene Kette ist immer noch intern konsistent. Das Erkennen von Abschneiden am Ende erfordert einen Anker von außerhalb der Datei – --expect-count, --expect-last-hash, einen OpenTimestamps-Anker oder conarium-reconcile gegen die eigenen Zähler der Datenbank.

(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

Ein zweiter Verifizierer, nur Go und die Standardbibliothek, befindet sich in verifiers/go. go build -o conarium-verify . dann die gleichen Argumente wie conarium-verify; test-vectors/ ist der Vertrag.

Opt-in-Ankerung: CONARIUM_ANCHOR_SINK=opentimestamps. Aktualisieren Sie ausstehende Beweise später mit npx conarium-anchor-upgrade ./audit.jsonl.anchors.jsonl. Der Client ist im Baum (Node crypto + Kalender-HTTPS). Er installiert javascript-opentimestamps nicht. Siehe LIMITATIONS.md.

Personenbezogene Maskierungsprofile

Maskierung, die für einen KI-Agenten richtig ist, ist für die Person, die die Daten besitzt, falsch. Der Eigentümer, der fragt "welcher Kunde schuldet am meisten", braucht den Namen; der Assistent, der Umsatz zusammenfasst, nicht. Das mit einem globalen Ein/Aus-Schalter zu beantworten, würde die einzige echte Garantie des Produkts deaktivieren, daher wird die Maskierung pro Person aufgelöst:

{
  "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" }
  }
}

Bewusst eng gehalten, denn dies ist die eine Funktion, die den Schutz lockern kann:

  • Ein Profil darf maskColumns, maxRows und maskLabelledNames überschreiben – und sonst nichts. Tabellen-, Tool- und Connector-Berechtigungen bleiben global; ein Profil kann niemals erweitern, was erreichbar ist, nur was darin lesbar ist. protectedColumns ist nicht überlagerbar: Ein Profil, das es entfernen könnte, wäre eine Hintertür pro Person.

  • Nur Benutzer-Tokens. Ein Akteur, der mit einem gemeinsamen Token authentifiziert ist, erhält niemals ein Profil. „Wer diese Zeichenkette besitzt, sieht unmaskierte PII" ist genau das Versagen, das dieses Produkt verhindern soll.

  • Überall sonst Fail-Closed: kein Akteur, nicht gelisteter Akteur oder ein Profilname, der nicht existiert, fallen alle auf die Basisrichtlinie zurück, niemals auf eine breitere.

  • Die Inhalts-Scanner laufen weiter. E-Mail-/National-ID-/Telefon-/Karten-/IBAN-/Geheimnis-Erkennungen sind überhaupt nicht überschreibbar, sodass diese in Freitext maskiert bleiben, egal welches Profil angewendet wurde. IBAN wird nur akzeptiert, wenn ISO 7064 mod-97-10 gilt. Pass-MRZ (TD3, 7-3-1 Prüfziffern) ist standardmäßig aktiviert und kann ebenfalls nicht durch ein Profil deaktiviert werden – nur policy.detectors.mrz: false auf der Basis-Richtlinie deaktiviert es. IP-Adressen sind aus, bis policy.detectors.ip: true gesetzt ist. Namensmaskierung ist der einzige Detektor, den ein Profil ausschalten kann (maskLabelledNames: false), weil der Verantwortliche, der seine eigene Kundenliste liest, der Fall ist, für den diese Funktion existiert.

  • Die Quittung sagt, welches Profil angewendet wurdepolicy.id wird zu conarium.policy/<profile>, innerhalb des signierten Hashs. Ein Zugriff, der unter einem gelockerten Profil erfolgt ist, kann später nicht als vollständig maskiert dargestellt werden. Das hält die Audit-Geschichte ehrlich: Es ging nie darum, „niemand sieht PII", sondern „jeder Zugriff ist regiert, und die Beweise sagen, unter welchen Regeln."

Namen in Freitext

Jede andere Kennung hat eine Form. Eine E-Mail hat ein @, eine National-ID hat eine Prüfsumme, eine Karte hat eine Länge – ein Regex entscheidet, und die Entscheidung reproduziert sich. Ein Name hat keine Form, daher war maskColumns das Einzige, das einen erfasst hat, und ein Name, der in eine Freitext-note getippt wurde, erreichte das Modell wörtlich.

Zwei deterministische Durchgänge schließen den Teil dieser Lücke, der ehrlich geschlossen werden kann:

Durchgang

Was es auslöst

Beispiel

Übertrag

Der Wert ist einer, den diese Richtlinie bereits in einer Spalte maskiert

customer_name is masked, so note: "Ayşe Demir called" is masked too — including across rows

Beschriftet

Der Text selbst markiert es: ein Titel oder ein Feldlabel

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

Was dies bewusst nicht tut: Ein bloßer Name im Fließtext wird nicht erkannt. „Ahmet hat gestern angerufen" geht durch. Das zu erkennen erfordert NER – ein Modell, ein Wörterbuch und einen Konfidenzwert – und jede Entscheidung, die dieses Gateway trifft, soll allein aus der Regel reproduzierbar sein, von jemandem, der uns nicht vertraut. Ein probabilistischer Maskierer wäre auch eine probabilistische Quittung. Werkzeuge, die NER ausführen (etwa Presidio-basierte), decken mehr Entitätstypen ab; sie erkaufen das mit einer Konfidenzschwelle. Keine Position dominiert – diese hier wird genannt, damit ein Prüfer weiß, welche er in Händen hält.

Von Inhalts-Scannern weiterhin nicht erfasst – bewusst, nicht aus Auslassung: Straßenadressen und bloße Namen. Ein Adressdetektor kann „Atatürk Caddesi No:15" nicht von „Atatürk Barajı" unterscheiden, ohne ein Ortsverzeichnis. Ein Namensdetektor kann Deniz / Güneş / Umut nicht von den Wörtern unterscheiden. Beides bräuchte ein Wörterbuch oder ein Modell; die Entscheidungen dieses Gateways sind deterministisch. Schließen Sie diese Lücken mit maskColumns (Spaltennamen) und conarium-suggest-policy (eine namenbasierte Vermutung, die Ihre Konfiguration nicht überschreibt).

IP-Adressen werden erfasst, wenn Sie sie aktivieren (policy.detectors.ip: true). Sie sind standardmäßig deaktiviert: Eine Server-IP ist nicht immer personenbezogene Daten, und eine Maske, die man nicht deaktivieren kann, behindert SOC-Arbeit. 1.2.3.4 ist strukturell eine gültige IPv4-Adresse; wenn der Detektor aktiviert ist, wird sie maskiert, selbst wenn Sie eine Versionsnummer meinten. Daten (13.08.2026) und Beträge (1.250,00) sind keine IPv4-Adressen.

Reisepassnummern in Freitext werden nicht erfasst. MRZ wird erfasst: zwei TD3-Zeilen × 44 Zeichen, P an Position 1, 7-3-1-Prüfziffern. Eine verfehlte Prüfsumme ist keine MRZ und bleibt unangetastet. TD1/TD2 sind nicht implementiert.

HTML &#64; / &#x40;, JSON \u0040 und %40 werden maskiert, wenn sie in einem E-Mail-förmigen Token sitzen. Ein einzelnes 5&#64; store oder C:\path\u0040abc bleibt unangetastet. Ein Dekodierdurchgang; &amp;#64; wird nicht weiterverfolgt.

Eine TCKN, die auf zwei gleichnamige Felder derselben Zeile verteilt ist (tckn_1 / tckn_2), wird maskiert, wenn die Verkettung die Prüfsumme erfüllt. Unzusammenhängende Spalten werden nicht kombiniert.

Nullbreitenzeichen, vollbreite Ziffern / und Unicode-Bindestriche werden vor den Detektoren entfernt oder auf ASCII abgebildet – dieser Durchgang ist kein allgemeiner Kodierungs-Decoder; umschlossene base64/hex-Tokens in einem Feld werden nur maskiert, wenn sie zu einem vorhandenen Detektortreffer dekodieren.

Scanlänge. Ein einzelnes Textfeld, das länger als policy.scanCharCap (Standard 16 384; Umgebungsvariable CONARIUM_SCAN_CHAR_CAP überschreibt) ist, wird als Ganzes durch [MASKED_PII] ersetzt, selbst wenn es keinen Identifikator enthält. Der Scanner wird nicht übersprungen: Überspringen würde bedeuten, dass eine lange Notiz, ein JSON-Blob oder eine Logzeile der Weg an der Maskierung vorbei wäre. Dies ist eine Benutzerfreundlichkeits-Einstellung. Eine Erhöhung lässt die Scan-Kosten quadratisch wachsen – ein 40-KB-alphanumerisches Feld dauerte ~1 s mit dem unbegrenzten E-Mail-Regex, bevor dieser Regex begrenzt wurde. maskedCount hält fest, dass eine Entscheidung getroffen wurde.

Übertragung ignoriert Werte unter drei Zeichen (ein Zwei-Zeichen-Wert passt überall und würde die Ausgabe zerfetzen) und gleicht an Unicode-Wortgrenzen ab, sodass Ali in Ali onayladı maskiert wird, aber nicht innerhalb von Kalite.

Abdeckung & Abgleich (Bypass-Erkennung)

Quittungen belegen, was durch das Gateway ging. Der Abgleich fragt die Datenbank, was sie gesehen hat, und vergleicht:

Keiner der Befehle erfindet seine Eingaben und conarium-init erzeugt sie nicht, also antworten beide mit 20 (Eingabe fehlt), bis Sie sie erzeugt haben: declaration.json ist Ihre eigene Zeitraum- und Umfangserklärung (docs/RECEIPT-SPEC.md benennt die Felder), und die beiden Snapshots stammen aus 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

Die Sprache ist bewusst gewählt: Abwesenheit wird als „Zugriff NICHT PROTOKOLLIERT" / „nicht quittiert" gemeldet, nie als „kein Zugriff erfolgte" – ein fehlender Datensatz ist von Natur aus mehrdeutig, und ein Werkzeug, das etwas anderes behauptet, belügt seinen Prüfer.

Am ersten Tag gegen unser eigenes Produktions-ERP ausgeführt, einschließlich eines echten Bypasses, den wir an uns selbst durchführten und den das Werkzeug erkannte: docs/dogfood/2026-08-06-reconcile.md.

Vollständiges Schema, Exit-Codes und bekannte Lücken: docs/RECEIPT-SPEC.md.

Gegenzeichnung (der Teil, den Sie nicht selbst erledigen können)

Quittungen belegen, was durch das Gateway ging. Der Abgleich belegt, dass nichts daran vorbei ging. Beides ist Ihr Eigentum, selbst gehostet und mit Ihrem eigenen Schlüssel signiert – was genau das ist, was ein Prüfer abwertet: Sie haben den Datensatz geführt, Sie haben ihn signiert, und Sie haben ihn gespeichert. Eine Gegenzeichnung beantwortet das, indem sie eine zweite Partei auf dieselbe Ketten-Spitze setzt.

Der Dienst ist in diesem Paket enthalten, sodass Sie Ihren eigenen ausführen und Ihre eigenen Spitzen signieren können – nützlich für einen zweiten internen Verwahrer und nutzlos gegen den obigen Einwand. Was ihn wertvoll macht, ist, dass der Unterzeichner nicht Sie sind.

# 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

Das Protokoll ist eine Hash-Kette: Einträge werden angehängt, nie neu geschrieben, und ein OTS-Zeitstempel deckt die Spitze ab, nicht jede einzelne Übermittlung. Was eine Gegenzeichnung beweist – und, ebenso wichtig, was sie nicht beweist – ist in docs/COUNTERSIGN.md ausgeführt, zusammen damit, was ein geleakter Signierschlüssel kosten würde.

Pro ist die gehostete Gegenzeichnung – jemand anderes als Sie signiert die Ketten-Spitze. 20 $/Monat oder 200 $/Jahr – sparen Sie 40 $. Ein Zeitraum, kein Abonnement. Es erneuert sich nicht von selbst – wenn der Zeitraum endet, endet der Zugriff, und Sie können ihn erneut kaufen. 14 Tage Geld-zurück ohne Fragen; danach keine Teilerstattungen. MwSt. wird wo anwendbar hinzugefügt. Der Checkout ist noch nicht geöffnet: conarium.dev/buy leitet zum Wartelisten-Formular weiter, bis der Zahlungsweg live geht, also sind diese Bedingungen der veröffentlichte Preis, nicht etwas, das Sie heute bezahlen können. Die Binärdatei oben ist das, was Sie selbst ausführen; Pro ist der zweite Unterzeichner. Seit 0.2.16 im Paket enthalten; der von VERAX betriebene Endpunkt ist für Kunden noch nicht geöffnet. Business bleibt auf der Warteliste: geplante Abgleiche, Abdeckungswarnungen und der signierte Zeitraumbericht sind im Vertrag, noch nicht ausgeliefert.

Das Format selbst implementieren

Die Quittung soll diese Implementierung überdauern, also wird sie mit Konformitätsvektoren ausgeliefert – zwölf eingefrorene Fälle plus ein maschinenlesbares Manifest in test-vectors/:

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

Richten Sie Ihren eigenen Verifizierer auf jede receipts.jsonl, übergeben Sie die in manifest.json aufgeführten Argumente und vergleichen Sie den Exit-Code. expected-hashes.json liefert die kanonischen JCS → SHA-256-Hashes, damit Sie Ihre Kanonisierung prüfen können, ohne unseren privaten Schlüssel zu benötigen, der bewusst nicht veröffentlicht wird.

Die Vektoren fanden beim ersten Lauf zwei Dinge in diesem Repository: eine Schema-Prüfung, die eine strukturell ungültige Quittung als manipuliert meldete, und eine falsche Annahme von uns über unsignierte Quittungen. Beides ist nun als Fall 007 und 008 eingefroren.

Verankerung Ihrer Kette (optional)

conarium-stamp verankert eine Datei bei den OpenTimestamps-Kalendern, und conarium-anchor-upgrade füllt die Bitcoin-Blockhöhe ein, sobald sie eintrifft. Diese beiden genügen für die meisten Einrichtungen.

Wenn Sie die Verankerung lieber als kleinen Dienst bereitstellen möchten – für mehrere Gateways oder um einem Prüfer eine stabile URL zu geben – bin/conarium-anchor-service.mjs ist einer: Er übermittelt Hashes, bewahrt Beweise auf, liefert die rohe .ots unter einem dauerhaften Pfad aus und aktualisiert ausstehende Verankerungen per Timer.

Es ist Code, den Sie ausführen, kein Dienst, den wir betreiben – es gibt keine gehostete Instanz, für die man sich anmelden könnte. Er liefert den rohen Beweis auch genau deshalb aus, damit ein Dritter mit dem Referenz-OpenTimestamps-Client verifizieren und den Dienst völlig ignorieren kann. Einen Verankerungs-Endpunkt, dem man vertrauen muss, würde den Zweck der Verankerung zunichtemachen.

Signieren ist fail-closed: Setzen Sie CONARIUM_AUDIT_SIGNING_KEY und/oder CONARIUM_AUDIT_HMAC_KEY, oder explizit CONARIUM_AUDIT_UNSIGNED=1 für Wegwerf-Einrichtungen. Schlüsselrotation: Behalten Sie frühere öffentliche PEMs in CONARIUM_AUDIT_TRUST_PUBKEYS (durch , / ; getrennt). Nach der ersten signierten Audit-Zeile muss jede spätere Zeile sig tragen.

Einordnung unter ähnlichen Projekten

Conarium ist nicht das erste Projekt, das signierte, verifizierbare Quittungen für KI-Aktivitäten erzeugt. Acta, Emilia Protocol, AuthProof, Agent Receipts und Invariant SVR tun alle eine Form davon, und einige sind uns bei der Standardisierung voraus – Acta und Emilia haben beide IETF-Internet-Drafts. Verwandte Forschung: Aegon (arXiv 2604.06693), Decentralised Trust Layers (ACM Web Conf 2026) und ISO/IEC TS 27560:2023 für signierte Einwilligungsdatensätze.

Diese Quittungen bezeugen, was ein Agent getan hat. Eine Conarium-Quittung bezeugt, was das Modell daran gehindert wurde zu sehen – weil die Komponente, die die Daten maskiert, dieselbe Komponente ist, die den Datensatz signiert. Durchsetzung und Beweis sind hier ein Teil, nicht zwei Systeme, die abgeglichen werden müssen.

Was wir verteidigen werden: Conarium ist die einzige uns bekannte Implementierung, die alle drei kombiniert: (1) Inline-Durchsetzung (Policy + Maskierung), (2) eine portable, offline verifizierbare Quittung dieser Durchsetzung und (3) Abdeckungsabgleich – Prüfung der eigenen Abfragezähler der Datenbank gegen die Quittungskette, sodass Zugriff, der das Gateway umging, aufgedeckt wird, statt unsichtbar zu bleiben. Quittungen zu signieren ohne durchzusetzen ist üblich; durchzusetzen ohne portable Quittungen ist üblich; beide Seiten gegen die eigene Buchführung der Datenquelle abzugleichen ist der Teil, den wir anderswo nicht gefunden haben. Ende-zu-Ende gemessen am Live-ERP eines echten operativen Unternehmens – 121.374 Datensätze, 121.366 Identitäten maskiert, 485.496 Felder maskiert, null an das Modell durchgesickert (Governance Report 001).

Was diese Zahl ist und was sie nicht ist. Sie stammt aus einem Batch-Lauf gegen das ERP unseres eigenen Unternehmens, und was sie stützt, ist eine hash-verkettete Audit-Datei mit 123 Zeilen, deren Arithmetik Sie selbst nachrechnen können und deren Kette 17 Tage später erneut verifiziert wurde. Was sie nicht stützt, ist eine Quittungskette: Dieser Lauf erzeugte Audit-Einträge, keine signierten portablen Quittungen, und sein Akteur ist eine Batch-Dienst-Identität, keine Person. Wenn Sie also fragen „zeigen Sie mir die Quittungen für diese 485.496 Felder", ist die ehrliche Antwort, dass sie nicht existieren – die Quittungskette ist eine separate und viel kleinere Messung. Skalierung und Offline-Verifizierbarkeit sind hier zwei verschiedene Behauptungen, und wir ziehen diese Linie lieber selbst, als dass Sie sie finden. Der Mechanismus ist verifizierbar, ohne uns zu vertrauen; diese besondere Zahl ist unsere eigene Messung, und Governance Report 001 listet ihre Grenzen auf.

Diese Behauptung ist absichtlich abgesichert, und docs/PRIOR-ART.md ist der Beleg dahinter: zehn Projekte, geprüft am 6. August 2026, was jedes einzelne hat, die nächste akademische Vorarbeit (Sello / Notarized Agents, die diese Lücke besser benennt als wir), und neun Dinge, die wir nicht verifizieren konnten. Wenn Sie eine Implementierung kennen, die alle drei kombiniert, eröffnen Sie ein Issue, und es wird korrigiert.


🏗️ Architektur (Das Dreigestirn)

Conarium arbeitet mit einer strengen dreiteiligen Architektur, die die Macht zwischen drei Säulen ausbalanciert:

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. Das Gateway: Ein Proxy, der fließend mit LLM-Assistenten spricht.

  2. Die Engine: Wertet JSON-Policies, Regex-Scans und Zeilenobergrenzen in Millisekunden aus.

  3. Das Ledger: Ein manipulationssicheres Audit-Protokoll, das jede Abfrage und jede Entscheidung aufzeichnet, die es vermittelt.


🚀 Schnellstart

# 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

Schritt 3 ist keine Dekoration. Eine fehlende Konfigurationsdatei stoppt das Gateway nicht – es startet mit null Konnektoren und regiert nichts – und ein Konnektor, der keine Verbindung herstellen kann, wird protokolliert, nicht ausgelöst. conarium-doctor benennt beides, beendet sich mit 1, wenn etwas nicht stimmt, sodass es ein Deployment absichern kann, und druckt nie ein Geheimnis, sodass seine Ausgabe sicher in ein Issue eingefügt werden kann.

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 weigert sich, vorhandene Dateien zu überschreiben, es sei denn, Sie übergeben --force. Es gibt den privaten Schlüssel nie aus — nur seinen Pfad.

Desktop-Verknüpfung für die Konsole

Der Policy-Editor ist npx conarium-console. Er bindet weiterhin an 127.0.0.1 und benötigt weiterhin ein Token. Diese zwei Befehle fügen lediglich eine Tür auf dem Desktop hinzu:

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

Windows

.lnk auf dem Desktop (Konsolenfenster minimiert)

macOS

~/Applications/Conarium Console.app

Linux

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

Ein Doppelklick startet dieselbe Konsole, wartet, bis der Port lauscht, und öffnet dann Ihren Browser. Das Token steht nicht in der URL; ein einmaliges Nonce (≤30 s) wird gegen ein Session-Cookie eingetauscht. Wenn bereits eine Verknüpfung mit diesem Namen existiert, wird ein -2-Suffix verwendet, statt zu überschreiben.

Exportieren Sie CONARIUM_CONSOLE_TOKEN vor --install-shortcut, damit der Launcher es aus ~/.conarium/console.token lesen kann (erstellt mit 0600). Die Verknüpfungsdatei selbst enthält das Token nicht.

Die Verknüpfung verwendet assets/conarium-mark.ico / .icns / -512.png, alle aus derselben SVG. Wenn diese Dateien fehlen, wird die Verknüpfung trotzdem erstellt und der Befehl gibt eine Warnung aus.

Der Tab Makbuzlar der Konsole listet signierte Belege aus audit.receiptSink (neueste zuerst) und zeigt dasselbe Beleg-HTML wie demo.conarium.dev/proof. Er verifiziert die Hash-Kette und schreibt zincir sağlam oder kırık (satır N). Wenn der Sink leer oder nicht gesetzt ist, wird das gesagt — es wird kein Beispielbeleg erfunden. Audit Logs bleiben die unsignierte Playground-Spur; sie sind keine Belege.

Wenn das Paket auf npm ist, werden dieselben Binaries im Tarball ausgeliefert (conarium-init, conarium-doctor, conarium-verify, conarium-suggest-policy). Bis dahin führen Sie sie wie oben aus diesem Repository aus.

Bevor Sie einen Bug melden: den Doctor ausführen

conarium-doctor prüft die Dinge, die still scheitern. Zwei davon sind am wichtigsten: Eine fehlende Konfigurationsdatei stoppt das Gateway nicht — es startet mit null Konnektoren und regelt nichts — und ein Konnektor, der sich nicht verbinden kann, wird geloggt, nicht ausgelöst, sodass der Prozess gesund aussieht, während er nichts bedient. Der Doctor erkennt auch das fehlende <pubkey>.keyid-Sidecar, das jeden Beleg als 13 verifizieren lässt (ließt sich wie Manipulation, ist es aber nicht).

Er beendet sich mit 0, wenn alles sauber ist, und mit 1, wenn etwas nicht stimmt, sodass er ein Deployment absichern kann. Er gibt nie ein Geheimnis aus — Passwörter, Token und Schlüsselmaterial werden nur als Form gemeldet (postgresql://appuser@db.internal:5432/prod (Passwort gesetzt, nicht angezeigt)), das heißt, die Ausgabe kann bedenkenlos in ein Issue oder eine E-Mail eingefügt werden.

Conarium spricht MCP über stdio, Ihr KI-Assistent startet es also als Befehl. Fügen Sie dies zu Ihrer MCP-Client-Konfiguration hinzu (z. B. Cursor):

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

⚙️ Konfiguration (Policy as Code)

Steuern Sie den Zugriff über eine einfache conarium.json-Policy-Datei:

{
  "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"]
}

Alles, was nicht in allowTables steht, ist standardmäßig verweigert; passende maskColumns werden zu [MASKED_PII] geschwärzt, bevor die Daten das Modell erreichen.

protectedColumns verwendet dieselbe Glob-Syntax. Jedes Muster wird auch im Ergebnis maskiert. Zusätzlich darf diese Spalte nicht in einem Prädikat (WHERE, HAVING, JOIN … ON, ORDER BY, GROUP BY) oder einem abgeleiteten SELECT-Ausdruck vorkommen — die Abfrage wird abgelehnt. Ein nacktes SELECT email ist weiterhin erlaubt und kommt maskiert zurück. Wenn das Feld weggelassen wird, bleibt das Verhalten unverändert. Ein Profil kann es nicht setzen. mssql / oracle verweigern den Start, wenn das Feld nicht leer ist: Diese Gates können keine Prädikatpositionen begehen, und dieses Produkt behauptet keine Regel, die es nicht durchsetzen kann.

policy.dialect wählt das SQL-Gate, das das query-Werkzeug verwendet: postgres (weggelassener Standard), mssql oder oracle. Es ist die Deklaration des Betreibers — Conarium errät den Dialekt nicht aus der Anweisung. Ein Tippfehler oder mysql lehnt die Konfiguration ab.

Konnektoren sind fail-closed. allowConnectors ist eine strikte Allow-List: Wenn sie fehlt oder leer ist, ist kein Konnektor erlaubt (zuvor bedeutete eine leere Liste „alle erlauben“). Wenn Sie Konnektoren konfigurieren, müssen Sie sie hier auflisten — andernfalls weigert sich der Server zu starten und teilt Ihnen genau mit, welches Feld Sie hinzufügen müssen. denyConnectors hat weiterhin Vorrang vor allowConnectors.

policy.detectors und policy.scanCharCap

Identitäts-Detektoren — TCKN, Karte, IBAN, E-Mail — können nicht abgeschaltet werden. Eine Konfiguration, die das versucht (detectors: { tckn: false }), wird beim Laden abgelehnt. Das ist das Produkt: Maskierung, die eine Bank per JSON-Datei deaktivieren kann, ist keine Maskierung.

Schlüssel

Standard

Warum

detectors.ip

false

Eine Server-IP ist nicht immer personenbezogen. Eine Maske ohne Ausschalter bricht SOC („Wie viele Anfragen von dieser Adresse?“). Opt-in, wenn die Spalte wirklich eine Client-Adresse ist.

detectors.mrz

true

Eine Pass-MRZ ist Identität und hat Prüfziffern. Schalten Sie sie in der Basis-Policy ab, wenn Sie keine Reisedokumente verarbeiten.

scanCharCap

16384

Benutzerfreundlichkeit. Felder, die länger sind, werden vollständig ersetzt ([MASKED_PII]), nie übersprungen. Env CONARIUM_SCAN_CHAR_CAP überschreibt. Erhöhen Sie den Wert, und die Scan-Kosten wachsen quadratisch. Obergrenze 1 048 576.

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

policy.customPatterns

Formate, die die eingebauten Detektoren nicht kennen — eine Bankkundennummer, ein Hauskontocode — können als zusätzliche Regeln auf dem selben Scanner registriert werden. Das ist kein zweiter Maskierungspfad und ersetzt maskColumns nicht.

Jede Regel benötigt einen Namen (das, was der Beleg aufzeichnet), ein Muster, optionale Spalten-Globs und ein Maskenlabel. Ein optionales sample ist das, womit conarium-doctor das kompilierte Muster testet — ein erfolgreicher Kompilierlauf ist kein Fang. Ein kaputtes oder ReDoS-förmiges Muster lehnt die Konfiguration ab; das Muster und das Sample werden nie in Logs, Belege oder Doctor-Ausgaben geschrieben.

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

Quantoren müssen beschränkt sein ({8}, {4,12}). +, *, verschachtelte Gruppen und Lookarounds werden beim Laden abgelehnt. Eine Regel benennt ein Format, das Sie bereits kennen; sie erfindet keins.

conarium-suggest-policy --sql schema.sql gibt eine maskColumns-Vermutung aus, basierend auf Spaltennamen (*name*, *address*, *tckn*, …). Es schreibt Ihre Konfiguration nicht. Die erste Zeile der Ausgabe sagt das.

🗺️ Roadmap

Conarium ist Early Access — und ehrlich, was real ist:

Jetzt verfügbar: verwaltetes MCP-Gateway (stdio + HTTP) · deterministische PII-Maskierung, einschließlich benannter Namen in Freitext · Allow/Deny + Zeilenobergrenzen · personenbezogene Maskierungsprofile · manipulationssicheres, hash-verkettetes Audit-Ledger · Ed25519-signierter Beleg pro Zugriff mit einem Offline-Verifizierer · signierte Abdeckungserklärungen · zweiseitiger Abgleich gegen die eigenen Zähler der Datenbank · OpenTimestamps-Ankerung und einen optionalen Ankerungsdienst · Konformitätsvektoren · SQL-Gate: Postgres, Microsoft SQL Server, Oracle (MySQL ist nicht implementiert; Oracle-Synonyme und Datenbank-Links werden nicht aufgelöst — siehe LIMITATIONS) · Postgres-, Supabase-, Docs-, OpenAPI-, Jira- und Slack-Konnektoren · conarium-init / conarium-doctor über npx (@conarium-ai/core).

Als Nächstes: Einwilligungsbindung (Spec veröffentlicht, kein Code — zuerst Patentprüfung) · eine zweite unabhängige Implementierung des Belegformats · pro-Benutzer-Identität, die an einen Identitätsanbieter gebunden ist, statt an eine Betreiber-Token-Zuordnung.

Bewusst nicht geplant, damit niemand darauf wartet:

  • LLM-basierte „semantische“ Maskierung. Das Gate ist absichtlich deterministisch. Eine probabilistische Maske würde einen probabilistischen Beleg ergeben, was kein Beleg ist.

  • Gehostete Cloud-Konsole. Self-Hosting ist das Versprechen; eine gehostete Konsole würde uns in den Datenpfad bringen, von dem wir sagen, dass wir nicht darin sind.

  • Keine SOC 2 für uns. In dieser Phase liegt die Priorität auf unabhängigen Penetrationstests und Assuranz auf Implementierungsebene statt auf organisatorischer Zertifizierung. Das betrifft unsere Zertifizierung, nicht Ihre: Die signierten Belege und Abdeckungserklärungen gehören Ihnen, um sie Ihrem eigenen Prüfer zu zeigen, und ob sie eine bestimmte Prüfung erfüllen, liegt zwischen Ihnen und diesem Prüfer. Falls wir jemals Ihre Daten halten oder ein Engagement von dem Zertifikat selbst abhängt, ändert sich dieser Satz zuerst.

Bekannte Lücken: LIMITATIONS.md, das README oben, docs/RECEIPT-SPEC.md, docs/BENCHMARK.md und docs/API-STABILITY.md.

📜 Lizenz

MIT — alles, einschließlich des Verifizierers, der Abgleichswerkzeuge und des Ankerungsdienstes. Es gibt keine Funktion, die für eine kostenpflichtige Stufe zurückgehalten wird; der Code ist MIT. Was conarium.dev verkauft, ist ein zweiter Signierer (Pro) und später betriebene Abdeckung (Business — noch nicht ausgeliefert) — nicht der Zugriff auf den Code.

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