Conarium
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.pemnote: 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- undfinancials-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 mitCONARIUM_NO_UPDATE_CHECK=1oder richten Sie es mitCONARIUM_NPM_REGISTRYauf 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-checkEin 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,maxRowsundmaskLabelledNamesüberschreiben – und sonst nichts. Tabellen-, Tool- und Connector-Berechtigungen bleiben global; ein Profil kann niemals erweitern, was erreichbar ist, nur was darin lesbar ist.protectedColumnsist 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: falseauf der Basis-Richtlinie deaktiviert es. IP-Adressen sind aus, bispolicy.detectors.ip: truegesetzt 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 wurde –
policy.idwird zuconarium.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 |
|
Beschriftet | Der Text selbst markiert es: ein Titel oder ein Feldlabel |
|
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 @ / @, JSON \u0040 und %40 werden maskiert, wenn sie in
einem E-Mail-förmigen Token sitzen. Ein einzelnes 5@ store oder
C:\path\u0040abc bleibt unangetastet. Ein Dekodierdurchgang; &#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 failedDie 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 14Das 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 casesRichten 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:#fffDas Gateway: Ein Proxy, der fließend mit LLM-Assistenten spricht.
Die Engine: Wertet JSON-Policies, Regex-Scans und Zeilenobergrenzen in Millisekunden aus.
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 conariumSchritt 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 startconarium-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-shortcutWindows |
|
macOS |
|
Linux |
|
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.
allowConnectorsist 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.denyConnectorshat weiterhin Vorrang vorallowConnectors.
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 |
|
| 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. |
|
| Eine Pass-MRZ ist Identität und hat Prüfziffern. Schalten Sie sie in der Basis-Policy ab, wenn Sie keine Reisedokumente verarbeiten. |
|
| Benutzerfreundlichkeit. Felder, die länger sind, werden vollständig ersetzt ( |
{
"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 toolsdescribe_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.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Schema-qualified table name | |
| connector | No | Connector name (optional) |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| connector | No | Connector name (optional, defaults to all) |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL SELECT query to execute | |
| connector | No | Connector name (optional, defaults to first allowed) |
TDQS
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.
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.
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.
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.
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.
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.
searchA
Find rows by a search term across the allowed tables — no SQL required. Read-only. Use it when the goal is to look up text and there is no SELECT yet; use query when a SELECT already exists. Returns matching rows under the same policy as query: capped by maxRows, with protected values already replaced by [MASKED_PII] or [MASKED_SECRET]. The policy decides which scopes are searchable at all. Every call is written to the audit ledger, and to a signed receipt as well when a receipt sink is configured.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term | |
| tables | No | Schema-qualified search scopes | |
| connector | No | Connector name (optional) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite the absence of annotations, the description discloses critical behaviors: read-only nature, result capping by maxRows, masking of PII/secrets, audit logging, and optional signed receipts. It also clarifies that the policy determines searchable scopes, giving the agent a solid mental model of side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense, with no fluff. It front-loads the core purpose, then gives usage guidance, return behavior, and audit details in four sentences, each earning its place. Perfectly sized for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, this description covers all necessary context: what it does, how it relates to the query sibling, what the returned data looks like (masked, capped), and the auditing side effect. There are no obvious gaps that would leave an agent confused about when or how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds useful context by explaining that the search runs across 'allowed tables' and that results adhere to the same policy as 'query', which enriches understanding of the 'tables' and 'query' parameters. It doesn't go into per-parameter syntax, but it doesn't need to; the brief schema descriptions are sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb+resource: 'Find rows by a search term across the allowed tables — no SQL required. Read-only.' It clearly distinguishes the search use case from the sibling 'query' tool, stating when to use which.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is provided: 'Use it when the goal is to look up text and there is no SELECT yet; use query when a SELECT already exists.' This directly names the alternative and sets a clear decision rule, which fully addresses when to use this tool vs. the main sibling.
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.
4 tool updates
v0.2.23- First observed
describe_table - First observed
list_tables - First observed
query - First observed
search
TDQS
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.
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.
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.
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
Related MCP Connectors
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
Runtime AI governance: decision gates, human approval, hash-chained audit, compliance mapping.
Governed AI actions with signed, verifiable receipts: free keyless reads, human-approved writes.
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceTamper-evident cryptographic audit trail for LLM outputs. Compliance logging for AI agent decisions.-
- AlicenseAqualityBmaintenancePrivacy-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.12MIT
- AlicenseAqualityAmaintenanceLocal zero-trust permission gateway for AI agents. Enforces policy-based tool authorization, human approvals, scoped permissions, and cryptographically verifiable audit logs.45Apache 2.0
- AlicenseNot gradedqualityBmaintenanceA 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
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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