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 -- das 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 sieben 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
Secrets in geschützte Textfelder auslagern	Feldwerte sind nicht Teil des Schemas
HTTP-Calls immer innerhalb von `do as server` ausführen	Verhindert, dass Zugangsdaten im Browser-Netzwerk-Tab sichtbar werden
`Lesbar wenn` auf Secrets nur für Admin erlauben	Je weniger Personen Zugriff haben, desto besser. Nur der Admin sollte Secrets kennen.
Secrets niemals mit der KI teilen	Nicht im Chat, nicht in Dateien, nicht in `.env`
Schema vor dem Teilen auf hardcodierte Secrets prüfen	Im Schema können Secrets von jedem gelesen werden, z.B. über den Network-Bootstrap-Call
Bei Verdacht auf Leak: Sofort rotieren	Credentials sind wie Generalschlüssel. 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. 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.

Was ist ein Datenbank-Schema?

Kurzfassung

Ein Datenbank-Schema ist der Bauplan deiner Datenbank. Es enthält alle Strukturen, Einstellungen und Scripte -- aber keine Daten. Ausnahme: Alles, was du direkt in Scripten als Text eingetippt hast ("hardcoded"), ist Teil des Schemas. Darum solltest du Secrets niemals als Text in Scripten eintragen.

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

Die Analogie: Backup ohne Häkchen

Wenn du in Ninox ein Backup erstellst und im Dialog alle Checkboxen abwählst (alle Häkchen entfernst), sicherst du nur das Datenbankschema -- also das Grundgerüst ohne Datensätze, Anhänge, Kommentare oder Änderungsverlauf.

Die Ausnahme: Hardcodierte Werte

Es gibt einen wichtigen Unterschied. 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. Schau dir dieses Beispiel an:

json

let myName := "Antje Götje";
"Hallo " + myName

Hier ist "Antje Götje" Teil des Schemas. Das ist meist unproblematisch. Aber stell dir vor, du schreibst:

json

let apiKey := "sk-ninox-12345-abcdef-SECRET";
http("GET", "https://api.ninox.com/...", {Authorization: apiKey}, {})

Oder:

json

let passwort := "SuperGeheimesPasswort123";
let basicAuth := "Basic " + passwort

Diese Secrets liegen nun im Schema. Jeder, der das Schema hat, kann sie lesen. Das ist das Kernproblem, das wir auf dieser Seite lösen.

API-Keys und Secrets schützen -- Innerhalb von Ninox

Kurzfassung

Alle Secrets gehören in geschützte Textfelder, nicht in Code. Nutze do as server für HTTP-Calls. Schränke den Zugriff auf den Admin ein. Besonders kritisch: Ninox API-Keys sind Domain-weite Master-Keys.

Im Detail

Warum API-Keys so kritisch sind

Domain-weit, nicht Team-weise

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

Das Admin-Dilemma in Ninox

In Ninox gibt es eine technische Realität, die das Thema Sicherheit komplex macht:

Schema-Änderungen erfordern Admin-Rechte: Um Tabellen, Felder oder Scripte zu ändern, muss ein Nutzer Admin sein
Admins haben Datenbank-weiten Zugriff: Auf der Datenbank-Ebene sind alle Admins gleichberechtigt. Wenn eine Tabelle für "Admin" sichtbar ist, können alle Admins sie sehen
Jeder Admin kann sich Zugriff verschaffen: Selbst wenn du den API-Key in einer geschützten Tabelle speicherst -- ein Admin könnte das Schema ändern und sich damit Zugriff verschaffen

Was bedeutet das praktisch?

Du kannst nicht alle anderen Entwickler ausschließen, denn irgendwann brauchst du vielleicht Unterstützung bei komplexen Anpassungen. Die Konsequenz:

Gib API-Keys nur vertrauenswürdigen Personen, die wirklich Admin-Zugriff brauchen
Ninox-Partner und externe Entwickler sollten den Key nur erhalten, wenn unbedingt nötig
KI-Agenten niemals: Sie sind keine Personen, haben keine Rechenschaftspflicht und speichern alles in Logs

API-Key im Textfeld speichern (nicht im Code)

Warum nicht im Code?

Wenn du einen API-Key direkt in ein Script schreibst ("hardcoded"), passiert Folgendes:

Der Key ist Teil des Schemas -- jeder, der das Schema exportiert, sieht ihn
Das Schema kann per Bootstrap-Call abgerufen werden -- auch ohne API-Key
Eine KI, der du das Schema gibst, kann den Key automatisch erkennen

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.

Die Einstellungen-Tabelle

Erstelle eine Seite namens Einstellungen. Darin speicherst du alle Secrets. 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(Einstellungen, 1).APIKey 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 oder Seite:

Öffne die Einstellungen der Tabelle oder Seite
Beim Feld Lesezugriff wähle im Dropdown nur admin aus (keine weiteren Rollen)
Alternativ oder zusätzlich: Trage im Formelfeld 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):

Öffne die Feldeinstellungen des API-Key-Textfeldes
Beim Feld Lesezugriff wähle im Dropdown nur admin aus
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

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 im 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)

json

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

Was passiert hier:

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

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

json

let meinApiKey := record(Einstellungen, 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)

json

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

Was passiert hier:

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

Alternative Variante: Direktzugriff

json

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

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

Wichtig: Kein Key außerhalb von do as server

Wenn du den API-Key außerhalb des do as server Blocks in eine Variable lädst, wird er an den Client übertragen. Selbst wenn du ihn nur für einen Moment speicherst, kann er abgefangen werden.

API-Keys und Secrets schützen -- Ausserhalb von Ninox

Kurzfassung

Teile API-Keys niemals mit KI-Agenten -- nicht im Chat, nicht in Dateien. Nutze für automatisierte Zugriffe einen Mittelsmann-Dienst wie n8n oder Make.

Im Detail

API-Keys und KI-Agenten

Warum .env-Dateien nicht sicher sind

Viele Entwickler kennen das Muster: Secrets in eine .env-Datei, Datei in .gitignore, fertig. Das funktioniert bei KI-Agenten nicht.

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. Du kannst ihm nichts verweigern.

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 der Chat nicht sicher ist

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

Im Verlauf der Konversation
In den Logs des KI-Anbieters
Möglicherweise in Trainingsdaten

Selbst wenn der Anbieter vertrauenswürdig ist: Ein Key im Chat ist ein Key zu viel.

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 Alternative: Mittelsmann-Dienste

Das Pattern: API-Key nirgends direkt

Anstatt den API-Key in deinem Code oder deinem KI-Projekt zu speichern, nutze einen Drittdienst:

Speichere den Ninox-API-Key NUR in n8n, Make oder einem ähnlichen Dienst
Diese Dienste verschlüsseln die Keys
Erstelle einen Endpoint in n8n/Make, der das Schema abruft
Schütze diesen Endpoint mit einem anderen Secret (nicht dem Ninox-API-Key)
Der KI-Agent ruft den n8n-Endpoint auf, nicht direkt Ninox

Die Sicherheitskette

KI-Agent --(Secret A)--> n8n --(Ninox API-Key)--> Ninox API

Der KI-Agent kennt nur Secret A. Das eigentliche API-Key liegt nur in n8n.

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.

Was tun, wenn ein API-Key kompromittiert wurde?

Kurzfassung

Sofort handeln: Neuen Key erzeugen, alten überall ersetzen, Zugriffe prüfen. Gehe davon aus, dass ein Key, der einmal geleakt ist, kompromittiert bleibt.

Im Detail

Schritt-für-Schritt Notfallplan

Wichtig zu verstehen

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

Neuen Key erzeugen
- Logge dich als Admin in Ninox ein
- Gehe zu den API-Einstellungen
- Erzeuge einen neuen API-Key
- Anleitung auf dem Ninox-Forum
Neuen Key einsetzen
- Aktualisiere das Textfeld in deiner Einstellungen-Tabelle
- Aktualisiere alle Mittelsmann-Dienste (n8n, Make)
- Prüfe alle Stellen, an denen der Key genutzt wird
Alten Key entfernen
- Lösche den alten Token in den Ninox-Einstellungen
- Nur das Erzeugen eines neuen Keys reicht NICHT -- der alte bleibt gültig, bis er explizit gelöscht wird
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 oder gelöschte Records
Was du nicht prüfen kannst:
- 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. Da Ninox keine Zugriffs-Logs führt, kannst du nicht erkennen, ob der alte Key noch verwendet wird. Lösche ihn umgehend.

Wenn Secrets hardcoded im Schema waren

Falls der Key (oder andere Secrets) hardcoded in deinen Scripten waren und du das Schema geteilt hast:

Gehe davon aus, dass die Secrets kompromittiert sind
Rotiere nicht nur den API-Key, sondern auch alle anderen betroffenen Credentials
Prüfe deine Scripte auf weitere hardcodierte Werte

Schema dem KI-Agenten bereitstellen

Kurzfassung

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

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. Wenn der MCP dein Schema abrufen könnte, bräuchte er deinen API-Key. Und das würde bedeuten: Die KI sieht deinen API-Key.

Sichere Methoden, das Schema zu teilen

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:

Speichere den Ninox-API-Key NUR im Mittelsmann-Dienst
Erstelle einen sicheren Endpoint
Der KI-Agent ruft diesen Endpoint auf
Das Schema wird übermittelt, 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?

Kurzfassung

Sensible Daten verlassen niemals deinen Rechner. Die Schema-Umwandlung passiert lokal. Ein optionaler, verschlüsselter Upload für Validierung ist in Planung.

Im Detail

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:

Der MCP-Server sendet ein Script an deine KI-Anwendung (Client)
Die KI führt das Script aus und wandelt die Schema-JSON in TOON (Token-Oriented Object Notation) um
Die TOON-Datei wird lokal bei dir gespeichert
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:

Dein TOON wird mit deinem MCP-API-Key verschlüsselt (nicht dem Ninox-API-Key)
Das selbe Script, das die Verschlüsselung durchführt, lädt das verschlüsselte TOON auf unseren Server hoch
Das TOON liegt für kurze Zeit (geplant: 7 Tage) verschlüsselt auf dem Server
Die Validierung findet statt: Das File wird kurzzeitig entschlüsselt, validiert, aber nicht als Klartext gespeichert
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.

Was NICHT übermittelt wird

Zusammenfassung -- an den GIP-MCP-Server gehen niemals:

Deine Ninox-API-Keys
Deine Datenbank-Datensätze (Records)
Deine Feldwerte
Unverschlüsselte Schemata

Dies gilt solange du keine Secrets hardcoded in deinen Scripten hast. Wenn doch, sind sie im Schema enthalten und somit potenziell sichtbar.

MCP und Sicherheit ​

Die wichtigsten Regeln auf einen Blick ​

Was ist ein Datenbank-Schema? ​

Kurzfassung ​

Im Detail ​

API-Keys und Secrets schützen -- Innerhalb von Ninox ​

Kurzfassung ​

Im Detail ​

Warum API-Keys so kritisch sind ​

API-Key im Textfeld speichern (nicht im Code) ​

Zugriff auf den API-Key schützen ​

HTTP-Calls korrekt aufbauen ​

API-Keys und Secrets schützen -- Ausserhalb von Ninox ​

Kurzfassung ​

Im Detail ​

API-Keys und KI-Agenten ​

Sichere Alternative: Mittelsmann-Dienste ​

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

Was tun, wenn ein API-Key kompromittiert wurde? ​

Kurzfassung ​

Im Detail ​

Schema dem KI-Agenten bereitstellen ​

Kurzfassung ​

Im Detail ​

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

Kurzfassung ​

Im Detail ​

TOON-Umwandlung (lokal) (geplant) ​

Verschlüsselter Upload für Validierung (geplant) ​

Was NICHT übermittelt wird ​

MCP und Sicherheit

Die wichtigsten Regeln auf einen Blick

Was ist ein Datenbank-Schema?

Kurzfassung

Im Detail

API-Keys und Secrets schützen -- Innerhalb von Ninox

Kurzfassung

Im Detail

Warum API-Keys so kritisch sind

API-Key im Textfeld speichern (nicht im Code)

Zugriff auf den API-Key schützen

HTTP-Calls korrekt aufbauen

API-Keys und Secrets schützen -- Ausserhalb von Ninox

Kurzfassung

Im Detail

API-Keys und KI-Agenten

Sichere Alternative: Mittelsmann-Dienste

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

Was tun, wenn ein API-Key kompromittiert wurde?

Kurzfassung

Im Detail

Schema dem KI-Agenten bereitstellen

Kurzfassung

Im Detail

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

Kurzfassung

Im Detail

TOON-Umwandlung (lokal) (geplant)

Verschlüsselter Upload für Validierung (geplant)

Was NICHT übermittelt wird