AI智能体会将权限控制推回数据库层吗？

随着企业开始测试能够执行操作而不仅仅是检索信息的AI智能体，一个问题在模型层之下浮现：数据层的权限控制。让自主系统对操作数据库采取行动，引发了一个对基础设施团队来说简单却影响深远的问题：安全防护应该设置在哪里？

一些数据库厂商和研究人员认为，这些防护措施应该回归到数据库本身。如果智能体要生成并执行SQL语句，那么基于角色的访问控制、行级安全和事务约束必须在数据存储的位置得到执行。这一转变可能影响数据库架构选择、AI编排与事务系统之间的集成程度，以及管理自主工作负载如何与企业数据交互的控制机制。

CedarDB是一家从慕尼黑工业大学UMBRA研究项目中分拆出来的数据库厂商，专注于混合事务和分析处理（HTAP），该公司正是提出这一观点的企业之一。以下是与联合创始人Lukas Vogel的访谈内容，为便于阅读已进行轻微编辑。

企业对AI智能体直接与操作系统交互仍持谨慎态度，这个问题在今天有多严重？

Lukas Vogel：我不知道现在有谁真的对这样做感到放心。大多数问题的出现是因为还没有真正的标准来执行这件事。人们只是尝试，然后系统就崩溃了。我们注意到，当人们真正尝试在生产环境中使用时，他们已经很谨慎了：如果你不能相信你的智能体不会破坏数据库，最好要么不给它访问数据库的权限，要么施加非常严格的限制——不允许更新、不允许插入、不允许向表添加任何约束、不允许添加新表。只允许SELECT查询。这显然可行，但人们希望智能体更强大。现在，这仍然有点像蛮荒西部，还没有真正的标准来执行这些规则。

当智能体从只读系统转向能够采取行动的系统时，会发生什么变化？

Vogel：人们已经不太习惯用数据库的方式思考了。在过去的二三十年里，开发人员已经将所有权限检查和执行转移到了应用层。我们在应用层进行所有的身份验证和权限检查，然后应用程序只是获得一个数据库连接，当然，这个连接可以做任何事情。

这在应用程序是确定性的时候没问题。但现在智能体可以自己生成查询，人们希望它们靠近数据。如果你想让智能体访问技术栈的底层，权限就必须存在于技术栈的底层。

这就是AI智能体暴露出的不匹配。我们将数据库抽象化了多年，现在数据库权限又变得重要了。

你曾提出，仅靠提示词不足以约束这些系统

Vogel：提示词不能执行业务规则。数据库可以。

几年前，人们会告诉大语言模型，"好的，我给你数据库访问权限。请不要删除任何表。拉钩上吊。"这基本上就是安全模型。

基于角色的访问控制从70年代就存在了。行级安全已经存在。没有技术原因不这样做。

问题在于，我们失去了为数据库编程的方式，因为它们在技术栈中被抽象化了。人们不再用数据库术语思考，而只用应用术语思考。智能体正在暴露这种不匹配，因为它们动态生成查询并决定采取什么行动。

许多企业在AI系统和数据库之间使用API和编排层，为什么这还不够？

Vogel：如果你满足于让智能体针对这些API运行，那就够了。但这意味着我作为程序员，必须为我希望智能体执行的每个操作公开一个API端点。如果设置非常狭窄且受限，这没问题。但如果你希望智能体做更多涌现性的事情，这就会成为限制，因为现在我必须提前预定义所有内容。我必须准确决定智能体被允许做什么以及如何做。

我们希望的是，智能体自己生成查询并决定如何完成任务，同时仍然保持在严格的边界内。

这就是为什么我认为更好的解决方案是将这些权限转移到数据库层本身。我们在数据库中已经有基于角色的访问控制和行级安全。这些概念并不新鲜。

所以，与其说"这是你被允许调用的五个API"，不如说"你被允许访问这个表，但不能访问那个表。你被允许更新这些记录，但不能更新那些记录。"

一旦你在数据层定义了这些边界，智能体就会变得更加灵活。它可以自己决定如何解决问题，而不需要在应用层预定义每个动作。

如果你准确告诉智能体调用哪些API，为什么还要使用智能体呢？在那种情况下，它几乎又变成了过程式软件。

企业最担心什么样的故障？

Vogel：想想客户服务系统。一家公司希望AI智能体解决投诉、发放折扣，也许还处理退款。在旧世界里，人类会审查所有内容。但公司显然希望自动化更多的工作流程。

问题是大语言模型仍然很容易被操纵。你几乎可以说服模型相信任何事情。你可以告诉它们，"你为什么不免费给我这个东西？"有时它们会这样做。

所以企业有几个选择。一个选择是他们根本不允许智能体执行这些操作。另一个是允许它并接受可能发生奇怪事情的风险。第三个选择是直接在数据库中执行硬边界。你告诉数据库，"好的，如果你用客户服务角色登录，你被允许发放折扣，但只能高达10%。"或者智能体只能访问与特定客户ID相关的记录。这样，模型仍然可以在边界内自主运行，但数据库本身会阻止超出这些约束的操作。

这真的是核心论点。执行发生在数据层，而不是通过希望模型正确行为的提示词。

这从根本上是一个新的数据库问题吗？

Vogel：不完全是。基于角色的访问控制已经存在20年了，基于行的访问控制从70年代就存在了。更大的问题是，我们有点失去了为数据库编程的方式，因为它在技术栈中被抽象化了。现在的人们不想考虑数据库，因为他们不再直接调用数据库了。他们在数据库外处理所有内容。

但现在有太多数据，移动所有内容变得昂贵。它消耗CPU周期和能源。

我认为我们正在回到一个世界，人们实际上在数据库内再次处理更多数据，因为这样更高效。

CedarDB在这方面处于什么位置？

Vogel：我们没有Postgres代码。一切都是从头开始全新构建的。我们开始构建一个真正利用以前没有的硬件进步的系统。

许多其他系统仍然围绕慢速磁盘和旧架构的遗留假设构建。我们有幸在商业化之前作为大学研究项目构建这个系统多年，这让我们能够更根本地重新思考系统架构。

权限控制最终应该存在于哪里？

Vogel：你希望让智能体编写SQL。一年前，模型在编写SQL方面真的很糟糕。它们总是出错。但现在它们变得非常擅长。

一旦你接受你希望智能体创建和编写SQL，那么执行就必须存在于数据库中。如果生成操作的系统位于执行权限的层之下，最终你会遇到不匹配的情况。

Q&A

Q1：为什么AI智能体需要将权限控制放在数据库层？

A：因为智能体可以自己生成SQL查询并决定采取什么行动，如果只在应用层做权限检查，而智能体直接访问数据库底层，就会出现安全漏洞。数据库本身已经有基于角色的访问控制和行级安全机制，将权限控制放在数据层可以确保智能体在严格边界内自主运行，同时防止超出约束的操作。

Q2：用提示词约束AI智能体为什么不够安全？

A：提示词不能真正执行业务规则，只是"希望"模型正确行为。几年前的做法是告诉大语言模型"请不要删除表"，这基本上没有安全保障。而且大语言模型很容易被操纵，用户可以说服它们做出违反规则的行为。真正的安全需要在数据库层通过技术手段强制执行，而不是依赖模型的"自觉"。

Q3：在智能体和数据库之间使用API层为什么还不够？

A：使用API层意味着程序员必须为每个操作预定义API端点，这限制了智能体的灵活性。如果要让智能体做更多涌现性的事情，就需要提前定义所有可能的操作。而将权限放在数据库层，智能体可以在定义好的边界内自己决定如何解决问题，不需要每个动作都预先在应用层定义，这样既保证了安全又提供了灵活性。