Wie Sie Datenbanken, Dateien und APIs zu einem kontrollierten Graphen für KI-Agenten vereinen: Praxiserfahrungen mit GraphJin MCP

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. In meinem DennisCraft AI Studio realisiere ich autonome Multi-Agenten-Systeme für DACH-B2B-Kunden – im Produktivbetrieb, nicht als Demo. Mein Stack: Claude, Supabase, n8n, Doppler, selbst gehostetes Postgres. Die Frage, die mich in jedem Projekt beschäftigt: Wie vereinen Sie relationale Datenbanken, Dateispeicher und externe APIs zu einem steuerbaren, DSGVO-konformen Graphen, ohne dass Agenten zu viele Rechte bekommen – oder an Berechtigungsfehlern scheitern?

Warum ein kontrollierter Datengraph für KI-Agenten nötig ist

Die Realität in regulierten Branchen: Daten liegen verteilt – in Postgres, Supabase, in REST/GraphQL-APIs, in S3-Buckets, als PDF oder CSV. Jeder neue Agent braucht eigene Integrationen und Zugriffsregeln, was die Komplexität und das Risiko exponentiell erhöht. Ohne zentrale Steuerung drohen entweder Datenlecks durch zu breite Rechte oder Automatisierungsabbrüche durch fehlende Freigaben – beides in DACH-typischen Compliance-Umgebungen inakzeptabel.

Insbesondere in Bereichen wie Logistik, Industrieautomation und Fintech ist strikte Zugriffs- und Audit-Kontrolle Pflicht, nicht Kür (siehe BSI Grundschutz, DSGVO).

Was GraphJin MCP im Betrieb wirklich löst (und was nicht)

Ich setze GraphJin MCP ein, um disparate SQL- und REST-Quellen in eine GraphQL-Schnittstelle mit feingranularer Zugriffssteuerung einzubinden – direkt auf bestehendem Postgres. Warum nicht Hasura oder PostgREST? GraphJin erlaubt YAML-basierte Feld-Policies, ohne dass ein Schema-Migration nötig wird. Aber: Dateispeicher (S3, Supabase Storage) müssen extern angebunden werden, out-of-the-box ist das nicht abgedeckt.

Tool	GraphQL-Schicht	RBAC-Granularität	Datei-/Blob-Support	API-Gateway
GraphJin MCP	Ja	Feldbasiert (YAML)	Indirekt (via Plugins/n8n)	Teilweise
Hasura	Ja	Tabellenbasiert	Nein	Nein
Supabase	Ja	Einfach	Nein	Nein

Mit GraphJin können Sie Agentenrechte in YAML pro Rolle und Feld steuern. Für Dateizugriff baue ich eine Proxy-Schicht mit n8n und Supabase Storage, sodass Dateien als Knoten im Graphen verfügbar sind.

Schmerzpunkte aus der Praxis

1. Dateien und Blobs als Teil des Graphen

Die größte Hürde: S3 oder Supabase Storage als echte Graph-Knoten verfügbar machen. Mein Ansatz:

Virtuelle Tabellen in GraphJin deklarieren, die n8n-Endpunkte für Dateioperationen mappen.
n8n übernimmt als Proxy die GraphQL-Anfrage, ruft Supabase Storage ab und liefert Datei-URL oder -Inhalt.


type File {
  id: ID!
  filename: String!
  url: String!
  metadata: JSON
}

# Beispielhafte GraphJin-Abfrage
query {
  files(where: {filename: {_ilike: "%rechnung%"}}) {
    id
    url
  }
}

Ergebnis: Jede Dateiabfrage durchläuft GraphJin → n8n → Storage-API. In Lasttests (1.000 Datei-Queries) lag die Latenz im Mittel bei 700ms – reine SQL-Abfragen lagen bei 120ms.

2. RBAC und feinsteuerbare Rechte

Feingranulares RBAC ist Pflicht: Ein Policy-Fehler und Agenten sehen zu viele Daten. Die Rechte werden in YAML abgebildet:


roles:
  agent_read:
    tables:
      files:
        select: true
        insert: false
        update: false
        delete: false
      sensitive_table:
        select: false

Ein YAML-Fehler – und der Agent bekommt 403 oder sieht zu viel. Schon einmal erhielt ein Agent versehentlich Zugriff auf Servicelogs. Empfehlung: Policy-YAML immer im CI prüfen (semgrep findet Policy-Lücken, siehe semgrep).

3. Logging und Auditierbarkeit

Für DACH-relevante Compliance (DSGVO, NIS2, ISO 27001) braucht es einen vollständigen Audit-Trail. Bei GraphJin+n8n landen Logs teils in Postgres, teils in n8n. Erst das zentrale Sammeln aller Logs in Grafana Loki macht eine revisionssichere Nachverfolgung möglich.


docker run -d \
  -p 3100:3100 \
  -v ./loki-config.yaml:/etc/loki/local-config.yaml \
  grafana/loki:2.9.0

Erst damit konnte ich zuverlässig nachvollziehen, welcher Agent wann auf welche Daten zugriff – ein Muss für Audits nach DSGVO und BSI-Grundschutz.

Absicherung gegen RCE und SQLi durch KI-Agenten

LLM-Agenten generieren teils unvorhersehbare Queries. In drei Produktivprojekten versuchten Agenten, per SELECT * FROM sensitive_table oder Subqueries via OpenAI Function Calling unautorisierte Daten zu ziehen.

Ohne Validierung in n8n und GraphJin droht SQL-Injection. Mein Tipp: Alle generierten Queries durch semgrep oder bandit prüfen – beide finden CWE-89-Muster (siehe OWASP SQL Injection).

FAQ

Wie schnell kann eine neue Datenquelle in den Graph integriert werden?

Mit GraphJin: 30–40 Minuten für Connection, Schema, YAML-Policy und n8n-Integration (bei APIs oder Dateien).

Wie bekomme ich einen vollständigen Audit-Log für Agentenaktionen?

Alle Logs aus GraphJin, n8n und Supabase zentral in Grafana Loki sammeln. Immer agent_id pro Event loggen.

Eignet sich GraphJin für Retrieval-Augmented Generation (RAG)-Agenten?

Ja, wenn Embeddings in Postgres liegen und im Graph deklariert werden. Für große Datenmengen empfiehlt sich aber faiss oder pgvector wegen Latenz.

Wie limitiere ich Agentenrechte auf Feldebene?

Mit GraphJin können Sie in YAML Feldrechte (z.B. E-Mail-Feld ausblenden) pro Rolle festlegen.

Was tun, wenn Agenten unautorisierte Queries stellen?

Validierung in GraphJin und n8n, plus manuelle Log-Review – im Produktivbetrieb zwingend nötig.

In welcher Schicht Ihrer KI-Architektur treten die gravierendsten Probleme auf: Dateiintegration, RBAC oder Audit-Logging? Das interessiert mich wirklich.

Ich biete einen kostenlosen 30-min Stack-Audit für DACH-Unternehmen mit KI-Projekten im regulierten Umfeld an. Kontaktieren Sie mich auf LinkedIn oder schreiben Sie an @ger_dennis_ai.