MCP und Sicherheit

Sicherheit bei der Arbeit mit Ninox, API-Keys und KI-Agenten muss nicht kompliziert sein. Auf dieser Seite erfährst du, wie du deine Secrets schützt. Secrets sind alle sensiblen Zugangsdaten wie API-Keys, Passwörter, Basic-Auth-Credentials und andere vertrauliche Tokens.

Besonderer Fokus liegt auf dem Ninox API-Key, da er domain-weit gilt und besonders mächtig ist. Die gleichen Schutzmaßnahmen gelten aber auch für alle anderen Secrets, die du in Ninox nutzt.

Die Erklärungen sind in zwei Ebenen unterteilt: Zuerst die Kurzfassung für schnelle Entscheidungen, danach die technischen Details für alle, die verstehen wollen, warum diese Regeln wichtig sind.

Die wichtigsten Regeln auf einen Blick

Wenn du dir nur eine Tabelle aus dieser Seite merken willst: Diese sechs Regeln schützen dich vor den gängigsten Sicherheitsproblemen, egal ob es sich um Ninox API-Keys, externe API-Keys, Passwörter oder andere Secrets handelt.

Regel	Warum sie wichtig ist
Secrets niemals im Code (Scripten) speichern	Hardcodierte Werte landen im Schema und sind für alle lesbar, z.B. über den Network-Bootstrap-Call
Secrets in geschützte Textfelder auslagern	Feldwerte sind nicht Teil des Schemas
Lesbar wenn auf Secrets nur für Admin erlauben	Je weniger Personen Zugriff haben, desto besser. Nur der Admin sollte Secrets kennen.
HTTP-Calls inkl. greifen des Secrets immer innerhalb von do as server ausführen	Verhindert, dass Zugangsdaten im Browser-Netzwerk-Tab sichtbar werden
Secrets niemals mit der KI teilen. Nicht im Chat, nicht in Dateien, nicht in .env	Es gibt diverse Angriffs-Vektoren auf KI-Systeme, die zu Datenlecks führen können. Man muss immer davon ausgehen, dass KI nicht sicher ist.
Bei Verdacht auf Leak: Sofort rotieren	Credentials sind wie Generalschlüssel, die Zugriff auf alles gewähren. Daher: Neue erzeugen, alte ersetzen, Zugriffe prüfen

Du bist für deine Secrets verantwortlich

Ein Ninox API-Key ist wie ein Generalschlüssel: Wer ihn hat, kann auf alle Teams deiner Domain zugreifen, und dort nicht nur das Schema abrufen und verändern, sondern auch alle Datenbankinhalte vollständig auslesen. Aber auch andere Secrets (externe API-Keys, Passwörter, Tokens) können großen Schaden anrichten, wenn sie in die falschen Hände geraten. Unser MCP fordert niemals deine Secrets an. Wenn die KI sie sehen kann, haben sie auch andere gesehen.

Wo lauern die Gefahren

Interne Angriffe

• Jeder Datenbank-Nutzer kann das Schema auslesen und damit auch hardcoded Secrets im Schema
• Wenn Secrets nicht korrekt im Ninox-Code aufgerufen werden, kann jeder Nutzer sie im Network-Call auslesen
• Wenn Felder oder Tabellen nicht korrekt geschützt sind, können unbefugte Nutzer in Datenfeldern hinterlegte Secrets lesen

Externe Angriffe

• Jeder mit Zugriff auf den API-Key kann alle Inhalte und Schemata aller Teams und Datenbanken der Domain abrufen
• Sobald eine KI die Secrets kennt, hat man eine Sicherheitslücke. Das betrifft auch alte Best-Practices wie .env-Dateien oder config.yaml-Dateien

API-Keys innerhalb von Ninox-Datenbanken

Was ist ein Datenbank-Schema?

Ein Datenbank-Schema ist der Bauplan deiner Datenbank: Es enthält alle Strukturen, Einstellungen und Scripte, aber keine Daten. Dieses Schema wird bei jedem Öffnen der Datenbank vom Ninox-Server übermittelt, damit dein Browser oder deine App weiß, was sie anzeigen soll. Dadurch ist das Schema aber auch ganz einfach von jeden Nutzer der Datenbank über die Konsole auslesbar.

Im Detail

Das Schema als Bauplan

Das Datenbank-Schema ist eine JSON-Datei, die den kompletten Aufbau deiner Ninox-Datenbank beschreibt. Es enthält:

• Alle Tabellen mit ihren IDs
• Alle Felder mit Feld-IDs, Feldtypen und Einstellungen
• Alle Scripte (Formeln, Trigger, globale Funktionen)
• Alle Layout-Einstellungen

Es enthält NICHT:

• Deine Datensätze (Records)
• Die eingegebenen Feldwerte
• Anhänge wie PDFs oder Bilder

Wie kann man das Schema auslesen?

Jeder Nutzer kann das Schema auslesen

Das Schema einer Datenbank bekommt man ganz einfach, indem man die Entwickler-Konsole des Browsers öffnet, in den Network-Tab navigiert und sich dort den Bootsrap-Call sucht. Dieser enthält die komplette Schema-JSON und kann von jedem ausgelesen werden, der die Datenbank öffnet, unabhängig von Rollen oder anderen Rechten.

Natürlich gibt es auch die Möglichkeit das Schema über einen API-Call auszulesen, aber dieser Weg ist über den Ninox-API-Key gesichert und nur für dich möglich - solange dein API-Key nicht öffentlich ist.

Hardcodierte Werte

Alles, was du als Text direkt in ein Script schreibst, ist Teil des Schemas. Das gilt nicht nur für Ninox API-Keys, sondern für alle Secrets: externe API-Keys, Passwörter, Basic-Auth-Credentials, Tokens. Jeder, der das Schema hat, kann sie lesen. Und wie wir eben festgestellt haben, hat jeder in deiner Datenbank auch Zugriff auf das Schema.

Wie gehe ich mit Secrets in Ninox korrekt um?

Wenn du Secrets in Scripten gespeichert hast, werden diese als Klartext im Schema übertragen. Dadurch können sie von jedem Nutzer direkt ausgelesen werden. Speichere deshalb niemals Secrets direkt im Code. Nutze stattdessen Datenfelder (Textfelder), die du mit Zugriffsbeschränkungen schützt (siehe Details für mehr Infos). Rufe deine Secrets nur innerhalb von do as server Blöcken auf:

let antwort := do as server
    let meinApiKey := record('API-Keys und Secrets', 1).APIKey;
    http("GET", "https://api.ninox.com/v1/teams", {Authorization: meinApiKey}, {})
end

Im Detail

Warum API-Keys so kritisch sind

API-Keys gelten für die gesamte Ninox-Domain. Wenn deine Domain mehrere Teams enthält, reicht ein einziger Key, um auf alle zuzugreifen. Ein einziger API-Call liefert die IDs aller Teams.

Das bedeutet, wer deinen API-Key hat, kann:

• Alle Datenbanken aller Teams sehen
• Records lesen und schreiben
• Datenbank-Schemata herunterladen
• Strukturen ändern

Es gibt ein Rollenmanagement für Ninox-API-Keys, wo du z.B. dem Key die Admin-Rolle entziehen kannst. Die korrekte Implementierung ist aber sehr komplex und wir haben in der Praxis sehr häufig Fehler in der Anwendung gesehen. Außerdem kann nicht jeder API-Endpoint mit einem eingeschränkten Key ausgeführt werden. Deshalb nutzen viele Entwickler trotzdem API-Keys mit Admin-Rechten. Da auch die eingeschränkten Keys immer noch ein Sicherheitsrisiko sein können, wenn auch ein etwas begrenzteres als der Admin-Key, betrachten wir im Folgenden alle API-Keys als gleichermaßen schützenswert.

Zugriff begrenzen

Weil API-Keys so kritisch für die Sicherheit sind, sollten sie nur an ausgewählte Personen / Organisationen weitergegeben werden. Die folgenden Fragen solltest du dir stellen, bevor du deine Secrets weiter gibst:

• Vertraust du der Person / Organisation und besteht ein Auftragsverarbeitungsvertrag / eine Geheimhaltungsvereinbarung?
• Benötigt die Person / Organisation deinen API-Key, um eine Schnittstelle für dich aufzubauen?
• Kannst du stattdessen die Daten selbst aus Ninox schicken bzw. aus Ninox heraus abrufen, um deinen API-Key nicht herausgeben zu müssen (Webhook)?
• Wird der API-Key in der anderen Lösung ausreichend (verschlüsselt) gesichert? Wer hat Zugriff auf deine Secrets?
• Welche anderen Systeme haben dadurch auf die API-Keys Zugriff? (Git-Repositories, OneDrive, Google Drive, KI-Systeme, Drittdienste, Kollegen oder externe Mitarbeiter, etc.)

Zusätzlich solltest du beachten, dass jeder Ninox-Entwickler, der in deinen Datenbanken als Admin Zugang hat, sich Zugriff zu allen in Datenfeldern oder im Schema gespeicherten Secrets verschaffen kann.

API-Key im Textfeld speichern (nicht im Code)

Alles, was du als Text direkt in ein Script schreibst, ist Teil des Schemas. Das gilt nicht nur für Ninox API-Keys, sondern für alle Secrets: externe API-Keys, Passwörter, Basic-Auth-Credentials, Tokens. Jeder, der das Schema hat, kann sie lesen, z.B. ein KI-Agent, der dir beim Programmieren hilft.

Warum in ein Textfeld?

Feldwerte sind nicht Teil des Schemas. Wenn du den API-Key in ein Textfeld der Tabelle (oder Seite) Einstellungen speicherst, bleibt er aus dem Schema heraus. Das ist die erste Verteidigungslinie.

Eine Ninox-Seite für API-Keys und Secrets

Erstelle eine Seite namens API-Keys und Secrets. Darin speicherst du alle Secrets und andere Credentials in Textfeldern. Schränke den Zugriff auf diese Seite auf den Admin ein.

Warum eine Seite? Ninox-Seiten bestehen immer nur aus einem Datensatz. Dadurch weißt du immer, dass du deine Secrets im Record mit der ID 1 findest und kannst sie mit record('API-Keys und Secrets', 1).NinoxApiKey direkt auslesen.

Zugriff auf den API-Key schützen

Der API-Key liegt nun in einem Textfeld. Aber wer darf das Feld sehen?

Option A: Tabelle/Seite schützen (empfohlen)

Nutze die rollenbasierte Berechtigung der Tabelle/Seite:

1. Öffne die Einstellungen der Tabelle/Seite
2. Beim Feld Lesezugriff wähle im Dropdown nur admin aus (keine weiteren Rollen)
3. Alternativ oder zusätzlich: Trage im Script für Lesbar wenn eine Bedingung ein, die nur für Admin true ergibt (z.B. userRole() = "admin")

Dies ist der einfachste und sicherste Weg. Der datenbank-weite Ausführungskontext für Lesbar wenn (ob "Client-seitig" oder "Server- und Client-seitig") spielt bei dieser Variante keine Rolle.

Option B: Nur das Feld schützen

Wenn die Tabelle/Seite gemischte Inhalte hat (z.B. auch Einstellungen, die andere Rollen sehen müssen):

1. Öffne die Feldeinstellungen des Secret-Textfeldes
2. Beim Feld Lesezugriff wähle im Dropdown nur admin aus
3. Stelle sicher, dass in den Datenbank-Optionen der Ausführungskontext für Lesbar wenn auf "Server- und Client-seitig" steht (nicht "Client-seitig")

Hinweis zum Ausführungskontext

Die Einstellung des Ausführungskontexts findest du in den Datenbank-Optionen. Ältere Datenbanken stehen oft auf "Client-seitig". Für Option B musst du dies auf "Server- und Client-seitig" ändern.

	Option A: Tabelle schützen	Option B: Feld schützen
Wann nutzen?	Tabelle enthält nur Secrets	Tabelle enthält gemischte Einstellungen
Wo einstellen?	Tabellen-/Seiteneinstellungen → Lesezugriff oder Lesbar wenn	Feldeinstellungen → Lesezugriff
Ausführungskontext	Egal (Client oder Server-Client)	Muss "Server- und Client-seitig" sein
Komplexität	Niedrig	Mittel
Sicherheit	Hoch	Hoch (wenn Kontext korrekt)

HTTP-Calls korrekt aufbauen

Die folgenden Schritte helfen dir nur dann deine Secrets sicher zu halten, wenn du alle zuvor besprochenen Schritte beachtet hast.

Client-seitig vs. Server-seitig

Wenn du einen HTTP-Call schreibst, passiert das in einem von zwei Kontexten:

• Client-seitig: Das Script läuft im Browser des Nutzers. Alle Netzwerk-Anfragen sind in den Entwickler-Tools sichtbar.
• Server-seitig (do as server): Das Script läuft auf dem Ninox-Server. Der Browser sieht nur das Ergebnis, nicht den Weg dorthin.

Die falsche Art (Client-seitig)

let meinApiKey := "sk-ninox-12345-SECRET";
let antwort := http("GET", "https://api.ninox.com/v1/teams", {Authorization: meinApiKey}, {})

Was passiert hier:

1. Der Browser führt das Script aus
2. Die Netzwerk-Anfrage enthält den API-Key im Klartext
3. Jeder Nutzer kann die Entwickler-Tools öffnen (F12) und den Key lesen

Auch falsch: Key außerhalb von do as server laden

let meinApiKey := record('API-Keys und Secrets', 1).APIKey;
let antwort := do as server
    http("GET", "https://api.ninox.com/v1/teams", {Authorization: meinApiKey}, {})
end

Auch hier ist der Key sichtbar, weil er außerhalb des do as server Blocks in eine Variable geladen wird. Der Wert wird an den Client übertragen, bevor der Server-Block ausgeführt wird.

Die richtige Art (Server-seitig)

let antwort := do as server
    let meinApiKey := record('API-Keys und Secrets', 1).APIKey;
    http("GET", "https://api.ninox.com/v1/teams", {Authorization: meinApiKey}, {})
end

Was passiert hier:

1. Der Browser schickt nur das do as server an den Server
2. Der Server führt den HTTP-Call aus
3. Der Browser sieht nur die Antwort, nicht den API-Key
4. Im Network-Tab steht Authorization: meinApiKey und nicht der Key selbst

Alternative Variante: Direktzugriff

let antwort := do as server
    http("GET", "https://api.ninox.com/v1/teams", {Authorization: record('API-Keys und Secrets', 1).APIKey}, {})
end

Diese Variante ist gleichermaßen sicher. Der einzige Unterschied: Im Network-Tab steht jetzt Authorization: record('API-Keys und Secrets', 1).APIKey statt Authorization: meinApiKey. Der Key selbst bleibt in beiden Fällen auf dem Server.

API-Keys außerhalb von Ninox-Datenbanken

Speichere deine Secrets niemals als Klartext in Dateien ab. Dazu zählen unter anderem .env-, config.yaml-, .txt-, .ini- oder skills.md-Dateien.

Synchronisiere deine Secrets niemals über Git, OneDrive oder ähnliche Systeme.

Noch wichtiger ist, dass du deine Secrets niemals mit deiner KI teilen solltest. Weder direkt über den Chat, noch durch Dateien in deinem Projekt, die deine Secrets enthalten. Auch .env-Dateien werden von der KI gelesen, .gitignore hilft hier nicht.

Nutze für automatisierte Zugriffe einen Mittelsmann-Dienst wie n8n oder Make, die deine Secrets verschlüsselt speichern.

Im Detail

API-Keys und KI-Agenten

Warum der Chat nicht sicher ist

Wenn du deinen API-Key in den Chat einfügst, landet er:

• Im Verlauf der Konversation
• Im Langzeitgedächtnis, wenn aktiviert
• In den Logs des KI-Anbieters
• Möglicherweise in Trainingsdaten

Wenn es zu einer Sicherheitslücke im KI-System kommt, ist damit dein Secret direkt kompromitiert, und du bekommst es möglicherweise noch nicht einmal mit. In den letzten Monaten waren solche Vorfälle wiederholt in den Schlagzeilen und stellen eine reale Gefahr dar.

Warum .env-Dateien nicht sicher sind

Viele Entwickler kennen das Muster: Secrets in einer .env-Datei speichern. Die Datei durch .gitignore vom Synchronisieren ausschließen, fertig. Das beeinflusst nicht deinen KI-Agenten.

Ein KI-Agent wie Cursor oder Claude Desktop hat Zugriff auf ALLE Dateien in deinem Projektordner. Er liest die .env-Datei genauso wie jede andere Datei. Alle Versuche, dies über rule-Files, Freigaberegeln bei tool-Calls und herstellerabhängige Einstellungen zu verbieten, sind nachweislich nicht wirksam.

Weiterführende Informationen

Dieses Problem wird in der Security-Community intensiv diskutiert:

• Prompt Injection bei KI-Agenten: So schützt ihr eure Entwicklungsumgebung vor unsichtbaren Angriffen: Erklärt, wie KI-Agenten unbeabsichtigt auf sensible Dateien zugreifen können
• Don't let AI read your .env files: Zeigt konkret, warum .env-Dateien bei KI-gestützter Entwicklung keine Sicherheit bieten
• LLM Security Risks: Übersicht über Sicherheitsrisiken beim Einsatz von LLMs in der Entwicklung

Warum Ninox-CLI im Projektordner kritisch ist

Ninox-CLI speichert API-Keys in einer config.yaml im Klartext. Wenn du Ninox-CLI in einem Ordner nutzt, auf den der KI-Agent Zugriff hat, sieht er auch die Keys.

Ninox-CLI und KI-Agenten

Nutze Ninox-CLI nicht direkt im Projektordner, auf den der KI-Agent zugreift. Extrahiere das Schema über einen sicheren Weg (siehe unten).

Sichere Alternativen

Wenn es nur um den Schema-Export geht

In unserer Fortgeschrittenen Anleitung findest du einen Code, mit dem du direkt in Ninox dein Schema herunterladen kannst. Ganz ohne API-Key oder Nutzung externer Dienste.

Mittelsmann-Dienste

Anstatt den API-Key in deinem Code oder deinem KI-Projekt zu speichern, nutze einen Drittdienst. Mit diesen kannst du z.B. dein Schema dynamisch abrufen oder andere HTTP-Calls ausführen:

1. Nutze einen Dienst, der deine API-Keys verschlüsselt aufbewahrt, z.B. n8n oder Make
2. Erstelle einen Endpoint in n8n/Make, der das Schema oder die benötigten Daten direkt abruft
3. Schütze diesen Endpoint mit einem anderen Secret (nicht dem Ninox-API-Key)
4. Der KI-Agent ruft bei Bedarf den n8n-Endpoint auf, nicht direkt Ninox. Der KI-Agent benötigt niemals den Ninox-API-Key!

Was tun, wenn ein API-Key kompromittiert wurde?

Sofort handeln:

• Alten Key löschen
• Neuen Key erzeugen
• Überall alten Key durch neuen Key ersetzen
• Zugriffe prüfen (in Ninox nicht möglich)
• Veränderungen an Schemata oder Daten prüfen
• Ggf. bestehen Meldepflichten nach DSGVO oder anderen Rahmenbedingungen

Gehe davon aus, dass ein Key, der einmal geleakt ist, kompromittiert bleibt!

Selbst den besten Entwicklern passiert es, dass ein Secret kompromitiert wird. Das ist ägerlich und zeitraubend. Aber nicht handeln ist schlimmer.

Im Detail

Schritt-für-Schritt Notfallplan

Wichtig zu verstehen

Da Ninox lesende Zugriffe nicht loggt, wirst du nie mit Sicherheit wissen, ob etwas und was genau mit einem kompromittierten Key abgerufen wurde. Gehe deshalb immer vom Worst-Case aus.

1. Lösche den alten Key und erzeuge einen neuen

   • Logge dich als Admin in Ninox ein
   • Gehe in die Ninox-Einstellungen und in den Bereich Integrationen
   • Lösche den kompromittierten API-Key
   • Erzeuge einen neuen API-Key
   • Anleitung auf dem Ninox-Forum

2. Neuen Key einsetzen

   • Aktualisiere das Textfeld in deiner API-Keys und Secrets-Tabelle
   • Aktualisiere alle Mittelsmann-Dienste (n8n, Make)
   • Prüfe alle Stellen, an denen der Key genutzt wird

3. Zugriffe prüfen: Die Ninox-Realität

   Limitierte Logging-Möglichkeiten in Ninox

   Ninox bietet keine Logs für lesende Zugriffe. Du kannst nicht nachvollziehen, wer wann welche Daten abgerufen hat. Auch Schema-Änderungen werden nicht geloggt.

   Was du prüfen kannst:

   • Änderungslog einzelner Records (wer hat Daten geändert)
   • Erstellte Records

   Was du nicht prüfen kannst:

   • Welche Records gelöscht wurden (außer durch Vergleich mit einem Backup)
   • Wer hat wann das Schema exportiert
   • Wer hat welche API-Calls ausgeführt
   • Wer hat auf welche Records zugegriffen

Der alte Key bleibt aktiv und du siehst keine Nutzung

Ein API-Key bleibt so lange gültig, bis er explizit in den Einstellungen gelöscht wird. Lösche ihn umgehend!

Schema dem KI-Agenten bereitstellen

Die Bereitstellung deines Schemas ist optional, aber hilfreich. Stelle sicher, dass es keine hardcodierten Secrets enthält, bevor du es teilst.

Nutze am besten die Schritte aus unserer Fortgeschrittenen Anleitung, um dein Schema direkt in Ninox herunterzuladen. Alternativ kannst du auch einen Mittelsmann-Dienst, wie n8n oder Make, nutzen.

Im Detail

Warum der MCP kein Auto-Fetch anbietet

Unser MCP bietet keine Funktion, um das Schema automatisch abzurufen. Das ist kein Fehler, sondern ein Sicherheitsfeature. Denn entweder müsstest du der KI deinen API-Key mitteilen, oder wir müssten deine und viele weitere Keys bei uns speichern. Hier zeigen wir dir zwei Methoden, wie der Schema-Abruf dagegen sicher geht:

Methode 1: Manuelles Exportieren (empfohlen)

Nutze das Ninox-Script aus der Fortgeschrittenen Anleitung, um dein Schema als Datei zu exportieren. Prüfe die Datei auf Secrets, bevor du sie dem KI-Agenten gibst.

Methode 2: Mittelsmann-Dienst

Wenn du das Schema dynamisch abrufen willst, nutze n8n oder Make:

1. Speichere den Ninox-API-Key NUR im Mittelsmann-Dienst
2. Erstelle einen sicheren Endpoint
3. Der KI-Agent ruft diesen Endpoint auf
4. Das Schema wird bereitgestellt, ohne dass der KI-Agent je den API-Key sieht

Vor dem Teilen: Auf Secrets prüfen

Bevor du dein Schema mit einem KI-Agenten teilst, musst du sicherstellen, dass keine Secrets enthalten sind. Das bedeutet: Suche in allen Scripten nach hardcodierten API-Keys, Passwörtern, Tokens oder anderen Zugangsdaten. Ein einmal geteiltes Schema kann nicht mehr zurückgenommen werden.

Was wird an den GIP-MCP-Server übermittelt?

An den GIP-MCP-Server gehen niemals:

• Deine Chats / Prompts an den KI-Agenten
• Deine Ninox-API-Keys
• Deine Datenbank-Datensätze (Records)
• Deine Feldwerte
• Unverschlüsselte Schemata

Was an den GIP-MCP-Server übermittelt wird:

• Kurze, gezielte Anfragen der KI im JSON-Format
• Im Fall von Script-Validierung: Das vom KI-Agenten erstellte Script und, bei Opt-In, das verschlüsselte Schema

Sensible Daten verlassen niemals deinen Rechner.

Im Detail

Was an den GIP-MCP-Server übermittelt wird

Dein KI-Agent schickt eine kurze, gezielte Anfrage an den MCP. Diese kann wie folgt aussehen:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "get_modules",
    "arguments": {
      "moduleIds": ["Card", "Grid"]
    }
  }
}

Dabei werden niemals Inhalte von deinen Prompts oder Chat-Verläufen mit dem MCP geteilt.

Wenn dein KI-Agent ein Script für dich geschrieben / bearbeitet hat, dann kann dieses zur Validierung an den MCP-Server übermittelt werden. Das Script wird aber nicht auf dem MCP-Server gespeichert, es wird nur die Validierungsantwort zurück geschickt.

Falls du dein Einverständnis gegeben hast, kann für eine bessere Validierung auch das Datenbankschema verschlüsselt an den MCP-Server übertragen werden. Das verschlüsselte Schema wird für 7 Tage gespeichert und danach gelöscht.

TOON-Umwandlung (lokal) (geplant)

Hinweis: Dieses Feature ist in Planung

Die folgende Funktion ist derzeit in Entwicklung. Du wirst sie nutzen können, sobald sie verfügbar ist.

Wenn du ein Schema zur Verarbeitung bereitstellst, passiert Folgendes auf deinem Rechner:

1. Der MCP-Server sendet ein Script an deine KI-Anwendung (Client)
2. Die KI führt das Script aus und wandelt die Schema-JSON in TOON (Token-Oriented Object Notation) um
3. Die TOON-Datei wird lokal bei dir gespeichert
4. Die KI kann nun effizienter mit dem Schema arbeiten

Dieser Prozess findet vollständig auf deiner Maschine statt. Der MCP-Server sieht weder Schema noch TOON in diesem Schritt.

Verschlüsselter Upload für Validierung (geplant)

Hinweis: Dieses Feature ist in Planung

Die folgende Funktion ist derzeit in Entwicklung. Du wirst sie nutzen können, sobald sie verfügbar ist, voraussichtlich mit einer Opt-in-Einstellung in deinem Profil.

Wenn du zugestimmt hast (Opt-in), läuft der Prozess weiter:

4. Dein TOON wird mit deinem MCP-API-Key verschlüsselt (nicht dem Ninox-API-Key)
5. Das selbe Script, das die Verschlüsselung durchführt, lädt das verschlüsselte TOON auf unseren Server hoch
6. Das TOON liegt für kurze Zeit (geplant: 7 Tage) verschlüsselt auf dem Server
7. Die Validierung findet statt: Das File wird kurzzeitig entschlüsselt, validiert, aber nicht als Klartext gespeichert
8. Das Validierungsergebnis wird zurück an die KI gesendet, ohne das Schema selbst

Was bedeutet "verschlüsselt mit deinem MCP-API-Key"?

Hier ist dein MCP-API-Key aus der Konfigurationsdatei gemeint: der Key, der die Verbindung zum GIP-MCP-Server herstellt. Er wird als Schlüssel für die Verschlüsselung genutzt, nicht als Dateninhalt.

MCP API-Key vs. Ninox API-Key: Was ist der Unterschied?

Es gibt zwei verschiedene API-Keys, die leicht verwechselt werden können:

MCP API-Key (dein GIP-MCP-Key)

• Wird beim Einrichten des MCP in deiner Konfigurationsdatei hinterlegt
• Authentifiziert dich beim GIP-MCP-Server
• Ist in der JSON-Konfigurationsdatei enthalten, die du von uns erhältst
• Der KI-Agent sieht diesen Key; das ist beabsichtigt und unproblematisch

Ninox API-Key (dein Domain-Key)

• Wird in der Ninox-Oberfläche erzeugt
• Ermöglicht Zugriff auf die Ninox REST API
• Muss nach den Regeln auf dieser Seite geschützt werden
• Sollte der KI-Agent NIE sehen

Zwei verschiedene Keys, zwei verschiedene Zwecke

Der MCP-Key ist dafür da, dass du unseren Server nutzen kannst. Der Ninox-Key ist dafür da, dass du auf deine Datenbank zugreifen kannst. Sie haben nichts miteinander zu tun.