2025-11-13T13:52:10.448421

Safe, Untrusted, "Proof-Carrying" AI Agents: toward the agentic lakehouse

Tagliabue, Greco

Data lakehouses run sensitive workloads, where AI-driven automation raises concerns about trust, correctness, and governance. We argue that API-first, programmable lakehouses provide the right abstractions for safe-by-design, agentic workflows. Using Bauplan as a case study, we show how data branching and declarative environments extend naturally to agents, enabling reproducibility and observability while reducing the attack surface. We present a proof-of-concept in which agents repair data pipelines using correctness checks inspired by proof-carrying code. Our prototype demonstrates that untrusted AI agents can operate safely on production data and outlines a path toward a fully agentic lakehouse.

academic

Safe, Untrusted, "Proof-Carrying" AI Agents: toward the agentic lakehouse

基本信息

论文ID: 2510.09567
标题: Safe, Untrusted, "Proof-Carrying" AI Agents: toward the agentic lakehouse
作者: Jacopo Tagliabue (Bauplan Labs), Ciro Greco (Bauplan Labs)
分类: cs.AI cs.DB
发表时间: 2025年10月10日 (arXiv预印本)
论文链接: https://arxiv.org/abs/2510.09567

摘要

数据湖仓(Data Lakehouse)运行敏感工作负载，AI驱动的自动化引发了关于信任、正确性和治理的担忧。本文论证了API优先的可编程湖仓为安全设计的代理工作流提供了正确的抽象。以Bauplan为案例研究，展示了数据分支和声明式环境如何自然地扩展到代理，实现可重现性和可观察性，同时减少攻击面。提出了一个概念验证，其中代理使用受证明携带代码启发的正确性检查来修复数据管道。原型展示了不受信任的AI代理可以安全地在生产数据上操作，并概述了通向完全代理化湖仓的路径。

研究背景与动机

问题定义

核心问题：随着LLM推理和工具使用能力的提升，如何让AI代理安全地管理数据湖仓中的数据生命周期，特别是在敏感的生产环境中？
挑战分析：
- 湖仓是为人类团队协作构建的分布式系统，处理敏感生产数据，不适合端到端自动化
- 平台异构性使得代理用例优先级不明确
- 传统系统因接口异构和复杂访问模式而抗拒自动化
现实需求：
- 数据工程师花费大量时间修复数据管道
- 管道修复是高风险非平凡场景的试金石
- 需要在保证安全性的前提下实现自动化

研究动机

实用价值：管道涵盖湖仓工作负载的大部分（按开发时间和总计算量衡量）
技术挑战：在高风险场景中测试代理渗透能力
系统需求：需要统一的接口来桥接代理、云系统和人类监督者

核心贡献

抽象设计：引入了在可编程湖仓中建模数据生命周期的抽象，通过代码完全构建和执行云管道
安全框架：回顾并解决了高风险工作负载自动化的常见反对意见，论证了模型在数据和代码工件方面促进可信性和正确性
原型实现：发布了工作代码，展示了使用Bauplan作为湖仓和代理循环的自修复管道概念验证
路径规划：基于原型概述了实现完全代理化湖仓的实际后续步骤

方法详解

可编程湖仓架构

管道定义

管道被定义为转换的DAG（有向无环图），具有以下特点：

@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()

关键设计选择：

FaaS抽象：业务逻辑表达为简单函数 Table(s) → Table
声明式I/O：函数完全隔离，Python环境声明式指定

管道执行

执行采用事务性模式，结合Git概念：

$ pip install bauplan
$ bauplan run --project_dir P_folder

事务性保证：

分支-合并模式：执行自动移动到写时复制分支
原子操作：只有成功的运行才会合并到主分支
沙盒写入：从生产读取但写入隔离，避免脏读

安全机制设计

四维安全检查表

关注点	模式	抽象机制
数据信任	数据访问	声明式I/O
代码信任	代码执行	FaaS运行时
数据正确性	数据完整性	事务性运行
代码正确性	代码质量	验证后合并

具体安全措施

数据信任：
- I/O始终由平台中介
- 代理无法访问物理数据层(S3)
- 基于API密钥的RBAC提供细粒度权限
代码信任：
- 函数作为独立进程运行，与主机和其他函数隔离
- 无互联网访问
- 声明式语法支持包白名单检查
数据正确性：
- 不完整管道不影响下游系统
- 人工审查可控制合并到主分支的权限
- 使用历史提交可随时恢复表
代码正确性：
- 采用"证明携带代码"协议
- 验证器函数 Branch → bool 允许代理分支合并
- 利用Git-for-Data的拉取请求流程

代理实现架构

系统组件

Bauplan：可编程湖仓平台
Bauplan MCP：将湖仓API暴露为工具
smolagents：ReAct框架，处理循环、工具调用和日志
多LLM支持：通过LiteLLM接口支持OpenAI、Anthropic、TogetherAI
验证器：合并前的"证明检查"步骤

工具能力

可观察性：获取失败作业及其日志
数据探索：查询表、检查类型
执行控制：创建分支、启动运行

实验设置

实验场景

故障模拟：基于行业报告和经验，模拟NumPy 2.0发布周围的包不匹配问题，导致使用pandas 2.0的容器崩溃。

技术栈

推理模型：Claude Sonnet 4.5等前沿模型
框架：smolagents (Python-based ReAct)
平台：Bauplan湖仓
数据集：NYC出租车数据集

评估维度

成功率：代理修复管道的成功比例
令牌使用量：完成任务所需的计算资源
工具调用次数：代理与系统交互的频率
安全性：系统在代理失败时的稳定性

实验结果

主要发现

模型性能差异显著：
- 前沿模型（如Sonnet 4.5）在成功率、令牌使用和工具调用次数方面表现差异很大
- 即使模型失败（如GPT-4-mini），湖仓也未出现中断或不安全行为
传统系统局限性：
- 行业领先的传统技术栈（如Snowflake + dbt）不支持代理修复
- 即使它们都有MCP服务器并服务重叠用例
- MCP是自动化的必要但非充分条件
系统灵活性：
- 模型切换仅需单一配置更改
- 支持预算约束场景中的步骤相关模型选择
- 数据分支支持大规模并发控制