TuBrief
구독 채널
비디오
커뮤니티

4 Sicherheitsvorkehrungen, die Sie treffen sollten, bevor Sie Daten-Agenten DB-Abfragen überlassen

TuBrief 편집팀
2026년 7월 23일
0
Computing/Software

원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.

Deutsch한국어EnglishEspañol中文العربيةहिन्दीFrançaisPortuguêsРусскийBahasa Indonesia日本語

관련 영상

Ship 26 NYC - 1.200 Analyseanfragen pro Tag: Clays und Vercels Einsatz für KI-native Analytics18:27

Ship 26 NYC - 1.200 Analyseanfragen pro Tag: Clays und Vercels Einsatz für KI-native Analytics

Vercel

커뮤니티의 다른 글

사내 시스템에 llm api 붙일 때 마주하는 현실적인 한계와 대응법

2026년 9월 13일

레거시 백엔드에 GPT-6 Astra 붙일 때 예산 승인과 보안 통과를 먼저 끝내는 법이 있습니다

2026년 9월 13일

에이전트끼리 대화하다 6천만 원 청구서가 나오는 이유

2026년 9월 13일

사내 RAG 벡터 검색에 Okta 권한 필터를 직접 거는 방법

2026년 9월 13일

브라우저 에이전트에게 내 구글 계정을 통째로 넘기면 안 되는 이유

2026년 9월 12일

Apple Won the AI Race

2026년 9월 12일

댓글 (0)

Log in to leave a comment

아직 작성된 글이 없습니다

© 2026 . All rights reserved.

TuBrief
구독 채널
비디오
커뮤니티
로그인

4 Sicherheitsvorkehrungen, die Sie treffen sollten, bevor Sie Daten-Agenten DB-Abfragen überlassen

Je mehr Jahre Erfahrung man in einem B2B-SaaS-Unternehmen sammelt, desto mehr wird man von Ad-hoc-SQL-Anfragen erdrückt. Aufgrund von einfachen Datenextraktionsanfragen aus den Fachabteilungen werden Kernaufgaben wie Infrastruktur-Upgrades oder Datenmodellierung immer wieder nach hinten verschoben. Die Einführung eines Text-to-SQL-Agenten scheint die Lösung zu sein, doch die direkte Anbindung generativer KI an die Produktions-DB ist der Beginn einer ganz anderen Katastrophe. Schließlich kann man die Daten nicht einfach übergeben, während man das Risiko von Sicherheitsvorfällen oder Serviceausfällen durch Halluzinationen in Kauf nimmt.

Letztendlich geht es im Kern nicht darum, sich auf ein paar Zeilen Software-Prompts zu verlassen, sondern eine Struktur zu schaffen, die Risiken auf DB- und Middleware-Ebene physikalisch blockiert.

1. DB-Sandbox: Schreibrechte blockieren und PII-Maskierung

Wenn Sie dem Agenten die vollen Lesezugriffsrechte auf die DB übertragen, setzen Sie sich dem Risiko von Prompt-Injection-Angriffen oder der Ausführung von DML durch Halluzinationen aus. Sie müssen bereits bei der Einrichtung von Nur-Lese-Konten gründlich ansetzen.

Wenn Sie den Treiber psycopg3 verwenden, geben Sie in den Verbindungseinstellungen explizit conn.set_read_only(True) an und aktivieren Sie default_transaction_read_only auf Session-Ebene. Das Auslösen einer Ablehnung aller Schreibversuche auf Ebene der Datenbank-Engine ist die sicherste Methode.

Um das Lecken von sensiblen Informationen (PII) zu verhindern, müssen Sie das Zugriffsschema innerhalb der Datenbank trennen.

  1. Installieren Sie das Erweiterungsmodul postgresql_anonymizer.
  2. Weisen Sie dem Agenten-Konto mit dem Befehl SECURITY LABEL FOR anon ON ROLE agent_readonly IS 'MASKED'; ein Maskierungs-Label zu.
  3. Erstellen Sie ein dediziertes Schema für den Agenten (analytics_views) und stellen Sie nur Views bereit, auf die Maskierungsfunktionen wie anon.random_phone() für E-Mails oder Telefonnummern der Quelltabellen angewendet wurden.
  4. Um eine Ressourcenmonopolisierung zu verhindern, sollten Sie strikte Session-Timeout-Einstellungen festlegen. Es wird empfohlen, statement_timeout auf 10000 (10 Sekunden), idle_in_transaction_session_timeout auf 30000 (30 Sekunden) und lock_timeout auf 5000 (5 Sekunden) einzustellen.

Durch das Aufsetzen einer solchen isolierten Umgebung können Sie das Risiko von Sicherheitsvorfällen verhindern und gleichzeitig die Engineering-Zeit, die für die Bearbeitung von Ad-hoc-SQL-Anfragen aufgewendet wurde, jede Woche um mehr als 15 Stunden reduzieren.

2. SQL-Validierungs-Middleware: AST-Analyse und Dry-run

Selbst wenn nur SELECT-Abfragen ausgeführt werden: Wenn die von der KI verfasste Abfrage einen Full Scan verursacht oder ein kartesisches Produkt (Cartesian Product) erzeugt, bricht die gesamte DB zusammen. Bevor die Abfrage an die DB übermittelt wird, muss sie auf Python-Middleware-Ebene zuerst eine Syntaxanalyse und Kostenbewertung durchlaufen.

  1. Konvertieren Sie die vom LLM generierte Abfrage mit der Funktion sqlglot.parse_one() der Python-Bibliothek sqlglot in eine AST-Struktur (Abstract Syntax Tree). Dies ist der Schritt, um grundlegende Syntaxfehler herauszufiltern.
  2. Führen Sie die AST-Traversierungsmethode walk() aus, um zu prüfen, ob verbotene Knoten wie exp.Delete, exp.Drop, exp.Update und exp.Create enthalten sind. Blockieren Sie die Ausführung sofort bei Erkennung.
  3. Führen Sie zuerst EXPLAIN (FORMAT JSON) mit dem Treiber psycopg3 aus. Konfigurieren Sie das System so, dass die Ausführung verweigert wird, wenn die zurückgegebene Total Cost einen Schwellenwert (z. B. 10000.0) überschreitet oder ein Seq Scan für Tabellen mit mehr als 100.000 Datensätzen sichtbar ist.

Wenn Sie solche Sicherheitsvorkehrungen in der Reihenfolge von Syntaxanalyse und Kostenbewertung platzieren, können Sie Infrastrukturstörungen oder Metrikfehler durch fehlerhafte Abfragen im Voraus verhindern.

3. CI/CD-Schema-Synchronisierung: LLM-Kontext auf dem neuesten Stand halten

Wenn sich das Schema durch dbt-Migrationen oder das Hinzufügen neuer Spalten ändert, aber veraltete Informationen im LLM-Prompt verbleiben, sucht der Agent nach nicht existierenden Spalten und wirft UndefinedColumn-Fehler aus. Nutzen Sie die bei der dbt-Kompilierung erzeugte target/manifest.json als einzige Quelle der Wahrheit (Single Source of Truth).

  1. Schreiben Sie ein Python-Skript innerhalb des dbt-Projekts, das nur Objekte extrahiert, deren resource_type unter den nodes-Einträgen der Datei manifest.json den Wert model hat.
  2. Extrahieren Sie Schemanamen, Tabellennamen, Spaltentypen und Description-Informationen in Form einer Markdown-Tabelle (prompts/context/schema_context.md).
  3. Binden Sie GitHub Actions ein. Sorgen Sie dafür, dass dbt compile und das Python-Skript automatisch ausgeführt werden, wenn Änderungen am Verzeichnis models/ in den main-Branch gepusht werden. Konfigurieren Sie die generierte Markdown-Datei so, dass sie mithilfe von stefanzweifel/git-auto-commit-action automatisch im Prompt-Repository committed wird.

Sie müssen Prompts nicht mehr jedes Mal manuell anpassen, wenn sich das Schema ändert, und können Ausfälle des Agenten aufgrund von Abfrage-Kompilierungsfehlern an der Quelle blockieren.

4. Autonome Korrektur-Feedbackschleife: Ergebnisvalidierung und Ausnahmebehandlung

Nur weil eine SQL-Abfrage ohne Fehler durchgelaufen ist, bedeutet das nicht, dass auch die Geschäftslogik stimmt. Sie benötigen eine Wiederholungsschleife, die Pandas-basierte Datenqualitätsvalidierung mit PostgreSQL-SQLSTATE-Fehlermeldungen kombiniert.

  1. Empfangen Sie das Ergebnis der Abfrageausführung als pandas.DataFrame und prüfen Sie, ob df.empty vorliegt. Wenn die Null-Quote der primären PK/FK-Spalten 50 % überschreitet, wird davon ausgegangen, dass ein fehlerhafter LEFT JOIN aufgetreten ist, und der Vorgang wird blockiert.
  2. Berechnen Sie für numerische Spalten den Z-Score ((df[col] - mean) / std). Wenn anomale Ausreißer über 4.0 erfasst werden, lösen Sie einen DataQualityValidationError aus.
  3. Wenn eine Validierung fehlschlägt oder ein psycopg.Error auftritt, führen Sie sofort db_connection.rollback() aus. Bündeln Sie anschließend den aufgetretenen PostgreSQL-Fehlercode (z. B. SQLSTATE[42703]) und den Grund für das Fehlschlagen der Validierung in einem Reflection Prompt und übergeben Sie diesen erneut an das LLM.

Um jedoch eine Token-Verschwendung durch Endlosschleifen zu verhindern, müssen Sie die maximale Anzahl von Wiederholungsversuchen (MAX_RETRIES = 3) unbedingt im Code angeben. Wenn Sie Fehlermeldungen erneut in den Prompt einspeisen, um eine autonome Korrektur zu ermöglichen, steigt die Abfragegenauigkeit im Vergleich zu einem einfachen Erstversuch deutlich an.