Sichere, nicht vertrauenswürdige "Proof-Carrying" KI-Agenten: Richtung des agentengesteuerten Lakehouse

Grundinformationen

• Paper-ID: 2510.09567
• Titel: Safe, Untrusted, "Proof-Carrying" AI Agents: toward the agentic lakehouse
• Autoren: Jacopo Tagliabue (Bauplan Labs), Ciro Greco (Bauplan Labs)
• Klassifizierung: cs.AI cs.DB
• Veröffentlichungsdatum: 10. Oktober 2025 (arXiv-Preprint)
• Paper-Link: https://arxiv.org/abs/2510.09567

Zusammenfassung

Data Lakehouses führen sensible Workloads aus, und KI-gesteuerte Automatisierung wirft Bedenken bezüglich Vertrauen, Korrektheit und Governance auf. Dieses Paper argumentiert, dass API-first programmierbare Lakehouses die richtige Abstraktion für sichere Agenten-Workflows bieten. Anhand von Bauplan als Fallstudie wird demonstriert, wie Datenverzweigung und deklarative Umgebungen natürlich auf Agenten erweitert werden, um Reproduzierbarkeit und Beobachtbarkeit zu ermöglichen und gleichzeitig die Angriffsfläche zu reduzieren. Ein Proof-of-Concept wird vorgestellt, bei dem Agenten durch Korrektheitsprüfungen inspiriert von Proof-Carrying Code Datenpipelines reparieren. Der Prototyp zeigt, dass nicht vertrauenswürdige KI-Agenten sicher auf Produktionsdaten operieren können, und skizziert einen Weg zu vollständig agentierten Lakehouses.

Forschungshintergrund und Motivation

Problemdefinition

1. Kernproblem: Wie können KI-Agenten mit verbesserter LLM-Inferenz und Tool-Nutzungsfähigkeit sicher den Datenlebenszyklus in Data Lakehouses verwalten, besonders in sensiblen Produktionsumgebungen?
2. Herausforderungsanalyse:
   • Lakehouses sind als verteilte Systeme für menschliche Teamzusammenarbeit konzipiert und verarbeiten sensible Produktionsdaten, die sich nicht für End-to-End-Automatisierung eignen
   • Plattformheterogenität macht Agenten-Use-Cases unklar priorisiert
   • Traditionelle Systeme widerstehen Automatisierung aufgrund von Schnittstellen-Heterogenität und komplexen Zugriffsmuster
3. Praktische Anforderungen:
   • Datentechniker verbringen erhebliche Zeit mit der Reparatur von Datenpipelines
   • Pipeline-Reparatur ist ein Prüfstein für hochriskante, nicht-triviale Szenarien
   • Automatisierung unter Beibehaltung von Sicherheitsgarantien erforderlich

Forschungsmotivation

• Praktischer Wert: Pipelines machen den Großteil der Lakehouse-Workloads aus (gemessen nach Entwicklungszeit und Gesamtrechenaufwand)
• Technische Herausforderung: Testen der Eindringfähigkeit von Agenten in hochriskanten Szenarien
• Systemanforderungen: Einheitliche Schnittstelle zur Verbindung von Agenten, Cloud-Systemen und menschlicher Überwachung

Kernbeiträge

1. Abstraktionsdesign: Einführung von Abstraktionen zur Modellierung des Datenlebenszyklus in programmierbaren Lakehouses, mit vollständiger Konstruktion und Ausführung von Cloud-Pipelines durch Code
2. Sicherheitsrahmen: Überprüfung und Adressierung häufiger Einwände gegen die Automatisierung hochriskanter Workloads, Argumentation, dass Modelle Vertrauenswürdigkeit und Korrektheit durch Daten- und Code-Artefakte fördern
3. Prototypimplementierung: Veröffentlichung von funktionierendem Code, der einen Proof-of-Concept selbstreparierender Pipelines mit Bauplan als Lakehouse und Agenten-Loop demonstriert
4. Pfadplanung: Skizzierung praktischer Folgeschritte zur Realisierung vollständig agentierter Lakehouses basierend auf dem Prototyp

Methodische Details

Programmierbare Lakehouse-Architektur

Pipeline-Definition

Pipelines werden als DAG (Directed Acyclic Graph) von Transformationen definiert mit folgenden Merkmalen:

@bauplan.model(materialization="REPLACE", name="A")
@bauplan.python("3.10", pip={"pandas": "2.0"})
def join_and_filter(
    trips=bauplan.Model("taxi_trips"),
    zones=bauplan.Model("taxi_zones")
):
    return trips.join(zones).do_something()

Schlüsseldesign-Entscheidungen:

1. FaaS-Abstraktion: Geschäftslogik ausgedrückt als einfache Funktion Table(s) → Table
2. Deklaratives I/O: Funktionen vollständig isoliert, Python-Umgebung deklarativ spezifiziert

Pipeline-Ausführung

Ausführung folgt einem transaktionalen Muster, kombiniert mit Git-Konzepten:

$ pip install bauplan
$ bauplan run --project_dir P_folder

Transaktionale Garantien:

• Branch-Merge-Muster: Ausführung wechselt automatisch zu Copy-on-Write-Branch
• Atomare Operationen: Nur erfolgreiche Läufe werden in Hauptbranch gemergt
• Sandbox-Schreibvorgänge: Lesen aus Produktion, aber Schreiben isoliert, verhindert Dirty Reads

Sicherheitsmechanismus-Design

Vier-Dimensionale Sicherheits-Checkliste

Spezifische Sicherheitsmaßnahmen

1. Datenvertrauen:
   • I/O wird immer durch die Plattform vermittelt
   • Agenten können nicht auf physische Datenschicht (S3) zugreifen
   • API-Schlüssel-basierte RBAC bietet granulare Berechtigungen
2. Code-Vertrauen:
   • Funktionen laufen als isolierte Prozesse, getrennt vom Host und anderen Funktionen
   • Kein Internetzugriff
   • Deklarative Syntax unterstützt Paket-Whitelist-Überprüfung
3. Datenkorrektheit:
   • Unvollständige Pipelines beeinflussen nicht nachgelagerte Systeme
   • Manuelle Überprüfung kann Merge-Berechtigungen in Hauptbranch kontrollieren
   • Historische Commits ermöglichen jederzeit Tabellenwiederherstellung
4. Code-Korrektheit:
   • Anwendung des "Proof-Carrying Code"-Protokolls
   • Validator-Funktion Branch → bool erlaubt Agenten-Branch-Merge
   • Nutzung des Pull-Request-Workflows von Git-for-Data

Agenten-Implementierungsarchitektur

Systemkomponenten

• Bauplan: Programmierbare Lakehouse-Plattform
• Bauplan MCP: Exponiert Lakehouse-API als Tools
• smolagents: ReAct-Framework, verwaltet Schleifen, Tool-Aufrufe und Logging
• Multi-LLM-Unterstützung: Unterstützt OpenAI, Anthropic, TogetherAI über LiteLLM-Schnittstelle
• Validator: "Proof-Check"-Schritt vor Merge

Tool-Fähigkeiten

• Beobachtbarkeit: Abrufen fehlgeschlagener Jobs und deren Logs
• Datenexploration: Abfrage von Tabellen, Typ-Überprüfung
• Ausführungskontrolle: Branch-Erstellung, Run-Start

Experimentelle Einrichtung

Experimentelles Szenario

Fehler-Simulation: Basierend auf Branchenberichten und Erfahrung wird ein Paket-Mismatch-Problem um die NumPy 2.0-Veröffentlichung simuliert, das zu Container-Abstürzen bei Verwendung von pandas 2.0 führt.

Technologie-Stack

• Inferenz-Modelle: Frontier-Modelle wie Claude Sonnet 4.5
• Framework: smolagents (Python-basiertes ReAct)
• Plattform: Bauplan Lakehouse
• Datensatz: NYC Taxi-Datensatz

Evaluierungsdimensionen

• Erfolgsquote: Anteil erfolgreicher Pipeline-Reparaturen durch Agenten
• Token-Nutzung: Erforderliche Rechenressourcen zur Aufgabenvollendung
• Tool-Aufrufe: Häufigkeit der Agenten-Systeminteraktion
• Sicherheit: Systemstabilität bei Agenten-Fehlern

Experimentelle Ergebnisse

Hauptergebnisse

1. Signifikante Modellleistungsunterschiede:
   • Frontier-Modelle (z.B. Sonnet 4.5) zeigen große Unterschiede in Erfolgsquote, Token-Nutzung und Tool-Aufrufen
   • Auch bei Modellfehlern (z.B. GPT-4-mini) traten keine Lakehouse-Unterbrechungen oder unsicheren Verhaltensweisen auf
2. Traditionelle Systemlimitierungen:
   • Branchenführende traditionelle Tech-Stacks (z.B. Snowflake + dbt) unterstützen keine Agenten-Reparatur
   • Auch wenn beide MCP-Server haben und überlappende Use-Cases bedienen
   • MCP ist notwendig aber nicht ausreichend für Automatisierung
3. Systemflexibilität:
   • Modellwechsel erfordert nur einzelne Konfigurationsänderung
   • Unterstützt schrittbezogene Modellauswahl in Budget-Constraint-Szenarien
   • Datenverzweigung unterstützt großflächige Concurrency-Kontrolle

Sicherheitsvalidierung

• Keine Produktionsunterbrechungen: Keine Produktionsdatenbeschädigungen in allen Experimenten
• Effektive Berechtigungskontrolle: RBAC- und API-Schlüssel-Mechanismen funktionieren ordnungsgemäß
• Transaktionale Garantien: Fehlgeschlagene Reparaturversuche beeinflussen nicht nachgelagerte Systeme

Verwandte Arbeiten

Data Lakehouse-Entwicklung

• Data Lakehouses sind De-facto-Standard-Architektur für Cloud-Analytics und KI-Workloads
• Profitieren von Storage-Compute-Entkopplung, Multi-Language-Unterstützung und einheitlicher Tabellen-Semantik

KI-Agenten-Tool-Nutzung

• Verbesserungen in LLM-Inferenz und Tool-Nutzung treiben autonome Entscheidungsfähigkeiten voran
• Existierende Infrastruktur-Agenten fokussieren auf spezifische Aufgaben, fehlt Unterstützung für vollständigen Lebenszyklus

Proof-Carrying Code

• Inspiriert von Necula und Lee's "Safe, Untrusted Agents Using Proof-Carrying Code"
• Angepasst an Datenumgebung, fokussiert auf Geschäftskontext statt formale Eigenschaften

Schlussfolgerungen und Diskussion

Hauptschlussfolgerungen

1. Programmierbare Lakehouses sind natürlich für Agentisierung geeignet: Deklarative DAGs und Git-ähnliche Datenverwaltung eignen sich hervorragend zur Unterstützung sicher gestalteter Agenten-Nutzung
2. Sicherheit kann garantiert werden: Durch angemessene Abstraktionen und Validierungsmechanismen können nicht vertrauenswürdige KI-Agenten sicher auf Produktionsdaten operieren
3. Praktikabilität ist validiert: Prototyp demonstriert erfolgreich Fähigkeit zur Pipeline-Reparatur in realen Szenarien

Limitierungen

1. Begrenzte Experimentskala: Aktueller Prototyp behandelt keine großflächige Parallelverarbeitung
2. Modellabhängigkeit: Leistung stark abhängig von zugrunde liegender LLM-Fähigkeit
3. Szenario-Spezifität: Hauptfokus auf Pipeline-Reparatur, andere Use-Cases erfordern weitere Validierung

Zukünftige Richtungen

1. Großflächige Parallelität: Hauptherausforderung für OLAP-Systeme im Zeitalter der Agenten-Datenexploration
2. Weitere Use-Cases: Erweiterung auf Datenqualitätsüberwachung, Leistungsoptimierung etc.
3. Standardisierung: Etablierung von Industriestandards und Best Practices für agentisierte Lakehouses

Tiefgreifende Bewertung

Stärken

1. Systematischer Ansatz: Erste systematische Adressierung der offenen Herausforderung der Cloud-Pipeline-Reparatur
2. Hoher praktischer Wert: Löst tatsächliche Schmerzpunkte von Datentechnikern
3. Sicherheitsdesign: Umfassendes Sicherheitsrahmenwerk, berücksichtigt mehrdimensionale Risiken
4. Open-Source-Beitrag: Bietet vollständigen funktionierenden Code für Gemeinschaftsreplikation und Verbesserung
5. Solide theoretische Grundlage: Basiert auf etablierten Theorien wie Proof-Carrying Code

Schwächen

1. Unvollständige Evaluierung: Mangel an systematischer Evaluierung in großflächigen, vielfältigen Szenarien
2. Plattformabhängigkeit: Stark abhängig von Bauplan-Plattform, Universalität zu validieren
3. Fehlende Kostenanalyse: Keine detaillierte Kosten-Nutzen-Analyse bereitgestellt
4. Fehlerbehandlungsmechanismus: Beschreibung der Behandlung komplexer Fehlerszenarien nicht ausreichend detailliert

Auswirkungen

1. Akademischer Beitrag: Bietet neue Forschungsrichtung für KI-Agenten-Anwendung in Dateninfrastruktur
2. Industrieller Wert: Bietet praktisch umsetzbares Lösungskonzept für Datenengineering-Automatisierung
3. Technologischer Antrieb: Fördert Entwicklung programmierbarer Dateninfrastruktur

Anwendungsszenarien

1. Unternehmens-Datenteams: Geeignet für Unternehmen, die Datenpipeline-Wartung automatisieren müssen
2. Cloud-Native-Architektur: Besonders geeignet für Organisationen mit API-first-Architektur
3. DevOps-Kultur: Geeignet für Teams mit starker DevOps-Kultur und Git-Workflow

Literaturverzeichnis

Das Paper zitiert 24 verwandte Arbeiten, hauptsächlich abdeckend:

• Data Lakehouse-Architektur (Zaharia et al., 2021)
• KI-Agenten-Tool-Nutzung (Shen, 2024)
• Proof-Carrying Code (Necula & Lee, 1998)
• Data Engineering-Herausforderungen (Data World, 2021)
• Programmierbare Infrastruktur (Tagliabue et al., 2024)

Gesamtbewertung: Dies ist ein Paper mit wichtigem praktischem Wert, das sich systematisch mit der sicheren Anwendung von KI-Agenten in Data-Lakehouse-Umgebungen befasst. Das Paper kombiniert theoretische Innovation mit praktischer Implementierung und bietet neue Perspektiven und Werkzeuge für Data-Engineering-Automatisierung. Obwohl Verbesserungen in der Evaluierungsvollständigkeit und Universalität möglich sind, verleihen die bahnbrechende Arbeit und Open-Source-Beiträge dem Paper bedeutenden akademischen und industriellen Wert.